Category Archives: Computers and Technology

I know some people have been wondering why Apple hasn’t updated the Mac Pro. Well, I think we know what they were waiting for…

Intel announces next-gen Thunderbolt with 20 Gbps throughput, 4K support:

Here at NAB, Intel just introduced the next generation of its Thunderbolt interface, which promises a data rate of 20 Gbps in both directions (on each of the two channels) as opposed to 10 Gbps for the previous version.

Why don’t MacBooks come with cellular networking? – Marco.org:

If Apple wants to offer 4G in MacBooks, they can start whenever they want. Doing it properly will just take a bit more effort than adding a modem.

I think it’s a bit more complicated than people think. 

Look at what Apple had to do with iPhone 5 to support LTE globally, vs. 3G. Lots more models of the phone because of the fragmentation of the LTE network frequencies. 

Translate that to the computer line, where even with Build to Order, Apple’s kept the number of models and the variations down to a minimum, and the trend has been towards fewer choices in recent models, not more. 

So to support 4D in the laptops, each laptop model is going to have to be set up to support 4G in all of it’s international variants. That complicates inventory and build management, distribution and etc. Don’t forget licensing and regulatory testing and approval — and the propensity for new models to leak via that process.

And don’t forget that 4G is only recently built out well enough to support widespread adoption in the US, and it’s adoption elsewhere is still rather — spotty. It’s one thing for Sprint to come out with a 4G model that sells 200 units in the US so the bleeding edge geeks can buy it (and mostly run it on 3G networks because they don’t have 4G yet) and giggle about how Apple’s so behind the times. It’s another to sell out a hundred million 4G iPhone 5′s in 40 countries. 

The combination of 3G speeds and build complexity/logistics made putting cellular into laptops fall in the “not worth it now” category. LTE changes that equation, but LTE’s only been in Apple’s product line a few months, and I expect Apple would want to prove out the networks and technology on the mobile devices before rolling it to the computers.

But I wouldn’t be at all surprised to see cellular support hit OS X at the next WWDC and roll out to the computers next fall, or this time next year. I would be surprised to see it happen sooner. And I’m not at all surprised it hasn’t happened by now, given the realities of how Apple builds laptops and what I see as consumer demand for this (which is: prior to LTE, very weak). 

But I’ll tell you, having recently upgraded from a first-gen iPad/WIFI to a Retina iPad/LTE, I’m sold. But I’m curious how they’re going to solve the issue of LAN vs WAN when it comes to things like devices in the home. Running both WIFI and Cellular in parallel? That’s very different than the IOS model…

App.net Developer Incentive Program – Marco.org:

An interesting idea: App.net will be paying “at least $20,000 per month” cumulatively to app developers, divided according to each app’s popularity and user satisfaction ratings. So a reasonably popular app might get a few thousand bucks a month.

It’s a strange move, though. It doesn’t look confident. This reminds me a bit of RIM’s strange $10,000-guarantee-if-you-make-at-least-$1,000 deal. (Apple and Google never needed to pay developers to make apps for iOS or Android.)

You’re trying to solve a chicken and egg problem here. 

Consumers are less likely to buy into a platform if “the apps they want” (see note 1) aren’t available for it. 

Developers are hesitant to commit to developing for a platform where the revenue opportunities aren’t there. 

The challenge is to bridge that gap for developers. You can

1. ignore it and pray
2. give them non-financial incentives, such as marketing and promotion, high profile in product launches, and other partnership goodies
3. pay developers to put apps on your platform (effectively, going to, say, Starbucks and offering to fund the app development for them)
4. subsidize the app ecosystem to get it off the ground and give developers a revenue stream until it grows enough to be sustainable on its own

For the first two, your platform needs to be pretty persuasive today if you want to go up against IOS and Android and expect developers to just wander in and play in your territory. When we were booting up webOS, it was (relatively) easy to do the “not Apple”, because Android hadn’t yet booted either, and all of the other platforms were missing or tightly managed. Today, booting a platform like webOS would be a lot harder, IMHO. 

So you need to inject money into the app ecosystem to help developers survive as it boots. Typically the worst thing you can do is pay developers to build apps; they’ll take the money, see how little of it they can spend to get an app out the door, and you get a crappy app and they don’t care because they’ve been paid. They invested in shipping the app, not investing in the ecosystem, and in lots of cases, will never care if it sells a copy. 

So it’s all about finding ways to build revenue into the ecosystem in ways that give incentive to both publish apps and to have those apps quality ones and well received by the users. with webOS, we did a series of promotions (please, god, don’t call them contests (see note 2)). With webOS, we tried to structure things to reward success with end users — most downloaded apps, for instance. With the Touchpad, we injected money into the ecosystem by attaching a $50 credit to every TouchPad sold, allowing buyers of the tablet to choose how to spend it. Both of them. 

FWIW, I’m not sure $20K a month will do a lot to boot the ecosystem. That doesn’t spread very far when you’re talking about trying to help developers pay back development expenses. For webOS, our budgets were more like a million a quarter, just for comparison. 

So both RIM and app.net are on the right track, if these are implemented properly. RIM’s guarantee makes sense because they’re trying to attract the class of developer/company that already has an IOS and an Android app and is saying “what’s in it for me? why should I bother?” — at least now, there’s some financial incentive, where, honestly, marketing/promotion or “hey, we’re not going to suck in year, you want to be part of this!” aren’t going to generate much enthusiasm. You put the $1000 floor on earnings to avoid getting flooded by five thousand tip calculator apps that exist only because people want  a chunk of the money you’re giving away. It saves you from paying out money to the, um, lower-caliber developers that are simply trying to grab your payout and not really trying to build a usable app that’ll help your platform. 

IOS doesn’t have to do this because they are the 800 pound gorilla, and have a zillion units in the hands of consumers looking for apps to buy. Ditto Android. What RIM is trying to do is get into that game again. It’ll be interesting to see whether they succeed. And they can’t do it by making promises or asking people to invest in building apps in hope of future returns. The class of app they need to attract will nod politely and then go plan their IOS next generation app instead. 

App.net is in a different place; I think this is more about encouraging some of the twitter developers to give them a shot, and to create an ecosystem where the developers have a bit of help so that they can give the apps the time for the platform to find a large enough audience. The developers that app.net are likely trying to attract are a lot different than the ones RIM need to grab (app.net is going to be the individual/homebrewer and the tiny shop, RIM needs corporate and mid-sized shops to buy in), but I still wonder if that amount will make a significant difference. We’ll see…

(note 1: “the apps they want” is actually fairly hard to define. There are likely 20-30 apps that are universal to almost everyone, from email and contacts and calendar and maps. There are a larger set of a few hundred that large chunks of potential buyers are going to want SOME of, whether it’s a Starbucks app or Netflix or their bank’s banking app or whatever. And most people have a couple of apps in the “gotta have” pile that are definitely niche apps, but the lack of them can be a killer. In my personal case, those “gotta have” niche apps are my birding and nature guides. A platform I can’t get those on I probably won’t consider, but 95 out of 100 readers of this blog post will shrug and go ‘huh?’? Everyone has those apps — and none of them are common apps in any way, shape or form, which is why you need to try to build a diverse and large app ecosystem. It’s basically the same reason why a steakhouse has a token chicken or fish dish on the menu: to prevent that one “I won’t eat beef” person from keeping the entire dinner party from coming to that restaurant…)

(note 2: the nanosecond someone utters the word ‘contest’ dozens of lawyers warp in through a wormhole and start having hissy fits. it turns out that having a contest is an incredibly complicated and regulated process and involves things like creating ways for people to enter without actually spending money or owning your product and things like that. So you end up sitting down with your lawyers and making damn sure you use language that doesn’t turn it into a contest. Even if it kinda looks and smells and quacks like one.)

There’s a new iPhone in town, and with it, a new release of IOS. The new iPhone is selling a zillion units and making Apple a few zillion dollars. Meanwhile, in some alternate universe, Dan Lyon is trashing everything in the hope that someone, somewhere, will link to him and maybe some folks will read his babblings again. Sorry, Dan, not me.

But with every release, it seems, the media and pundits have to find something to turn into a Major Crisis, and for IOS 6, that crisis is the new Maps. Apple’s removed the old Google Maps and replaced it with their own. Horrors, it’s got issues. Horrors, it’s not perfect. Obviously, this is the death of Apple. (But before you declare that, go read Kontra).

The fact is, the only thing more trendy than finding excuses to complain about Apple is buying their products. Which drives the complainers crazy, it seems. So every time Apple releases new products people find reason to complain and declare doom, and every release those declarations of doom are roundly ignored and the product goes on to be a massive success.  Fact is, not having a controversy to generate page views over is bad for business for many of these blogs and media sites, so of course they’re going to find a controversy. “Hey, damn, this is great” doesn’t trigger outraged comments and doesn’t drive eyeballs or ad rates or readership. And frankly, there are segments of the geek/tech pundit crew that seem to have hit that point where if we gave them unicorns, they’d complain about them being purple instead of blue. And if we gave them unicorns two years in a row, they’d complain, because unicorns are boring and the industry is really demanding dragons now. 

Honestly, it’s pretty sad to watch. But I don’t expect it to change any time soon. 

The fact is, the maps we get with IOS 6 are mostly okay and definitely have some bugs in the system. It’s not as good as Google’s maps, especially away from North America. And the vast majority of users won’t ever notice, because their usage of maps is very casual. I’m sure Apple’s also going to be working hard in the background to clean up the issues and fix the problems that get reported to them. In six months, this whole thing will be largely forgotten, except for a couple of tumblr blogs nobody will visit until the next iPhone release when the pundits do their “remember when?” articles… 

This all sound familiar? It should. It sounds a lot like Antennagate (iPhone 4). And the MobileMe Launch, which was never a great product, but pretty quickly became a decent and boring one. Remember when Apple revamped iMovie? or Final Cut? 

Fact is, Apple isn’t afraid to take apart a product and push it in another direction if they feel it’s the right thing to do over the long term. Today, Antennagate has been proven to be a lot of smoke over very little fire. MobileMe moved forward and became iCloud, which is a huge part of MacOSX and IOS now, and is mostly ignored by the tech press because, well, it’s decent and boring. iMovie is back to being a pretty good consumer product, and Final Cut is actually pretty well liked in the advanced consumer and prosumer segments, which is where Apple wants the product to live. (pretty much everyone I saw that had a cow over the new Final Cut replaced it with a 5 figure Avid system — i.e., people who spend lots of money on their setups. And they had some legitimate issues over being abandoned by Apple, but Apple also has a right to choose that it doesn’t want to support a market segment any more, too)

Maps are headed down that path, too. Apple bought it’s first mapping technology company (Placebase) back in 2009. In fact, do a google search on Apple and Placebase, and you can see all of the articles written at that time about how Apple was replacing Google Maps. Here we are, three years (and at least three mapping technology buys) later, and they actually did it. 

There’s been some amount of “we don’t know who pushed who into removing Google Maps” speculation going on. Honestly, given Apple’s been working on this at least four years, it’s hard to think Google pulled the trigger on this. More likely? The last time Apple and Google renewed the agreement on the maps, Apple came away from that thinking that they needed an alternative to Google before the agreement needed to be renewed again. Did Apple see Google boost  the cost of the technologies and have no choice? Perhaps. Whatever, I think it’s pretty safe to say that Apple’s been planning this for a while.

The big question that’s been asked is “how could Apple ship something this buggy?” To which my answer is: “Have you ever tried to debug a data set like this?”  I’ve seen a lot of writers complaining about the quality of the data. I’ve only seen two offer substantive suggestions on what Apple needs to do to fix it (and both are mapping industry insiders). I haven’t seen anyone offer any real suggestion on what Apple could have done, other than vague “it needed more testing”. 

Data sets like this frankly defy testing. The only reason Google Maps is as good as it is today is it has a multi-year head start at fixing reported bugs. Ultimately, the only way you clean up a data set like this is to shove it out into the real world and take your lumps while you and your users beat it into shape. 

Let me offer a similar problem I’m intimately familiar with. Someone dumps a list of 50 million email addresses on your desk (or in your Dropbox). Your job is to debug and clean up that data. How do you do that?

It is possible to find and fix/delete syntactically broken email addresses (although honestly, there are a bunch of RFC822-legal email addresses in the edge cases  that I promise you will fail or destroy pretty much every production email system out there, which is okay, because nobody uses them. So do you clean up this list to be correct to the standard? Or do you define a subset of the standard and clean up to that?  – even answering the question “what is a legal and valid email address?” is subjectively complex)

You can come up with lists of domains or account names you know you want to exclude from the list. Domains like “whitehouse.gov” probably shouldn’t be on there. Role accounts like “abuse@” or “root@” shouldn’t, either. You can also come up with specific email addresses you know you should exclude, like “stevejobs@apple.com” or “billgates@microsoft.com”. You can snuff out email addresses for which there’s no valid DNS and/or MX records and are therefore not routable (but there are complexities to that, too. In reality, you probably want to mark them and try at least three times over a two week period to get away from transient issues…)

In the end, what do you have? A list of email addresses that is somewhat smaller than the original list, one that you’ve been able to remove the typos and syntax errors and some percentage of the abuse/attack and other problem accounts. You have a list that you can pretty much guarantee is conformat. 

But that’s about it. Do you know if it’s a good list? A bad list? Are those email addresses valid? they’re syntactically correct, but do those addresses exist and are there people reading email sent to them?

You still have no idea. And you won’t, until you actually start sending email out to the list. 

Welcome to Apple’s Maps problem, except this list of 50 million email addresses is a LOT simpler and a much smaller data set than the mapping data. 

Do more testing? Anyone have an idea how much testing Apple did? (I don’t). But I know if I have a list of 50 million emails, you could hire me a hundred temps for a month to roll through the data and it wouldn’t significantly change the quality of the list. We could identify more problem emails and remove them, but honestly, that’s a lot of work when sending emails and trapping the bounces would do the same for a lot less time and money. 

The mapping problem is the same problem (only a lot bigger and harrier). Would hiring a thousand temps for six months solve the problems we see in this release of IOS? 

It’s solve some of them. If a tester happened to look at the imagery of the Tacoma Narrows bridge, it’d be obvious there was a problem that needed to be fixed. But what percentage of the maps are we going to cover, and how are we going to cover it? do you think that even with a huge set of testers looking at random data sets out of the mapping data that particular problem would show up in the testing? Could you build a team that could cover, say, 10% of the mapping data in any time worth doing? And at what cost?

But think about some of the other problems we’ve heard about, such as an airport being turned into a farm. Would a random tester viewing that random map page have a chance of finding that problem? It looks just fine: it’s syntactically correct, just like those emails. It’s just wrong. 

So if you want to debug something like map data, the only way to do tehat would be to build a testing team that has members with local knowledge of widely distributed locations and have them debug the areas of their expertise. In other words, you’d need to hire a global team and coordinate their testing globally as each group tests their local part of the data. How granular should these global teams be? Would a team based in Cupertino recognize a missing airport outside of Cody Wyoming? 

Hopefully you start to see the scale of the challenge. At some point with that list of 50 million emails, you have to say “okay, let’s use it and see what happens” — and then capture the feedback (bounces, complaints, etc) and fix it as you go along.

Same with the maps. At some point “do more testing” doesn’t actually improve the quality of the data, it just costs you time and money. 

That’s the point Apple is at now. Where the maps go from here depends on how well Apple is set up to receive, evaluate and repair complaints from users. 

This is a new class of problem. The Maps looks like an app, smells like an app, and it walks like an app, but in reality, the vast majority of the guts of it is a huge database that’s living in a server, so you can’t treat it or test it like an app, and the old school testing techniques for an app fail miserably. These “big data” solutions are still an emerging part of the industry, and how to deal with, test and evaluate the data is still something everyone is grappling with — just ask any Hadoop geek. 

But I think a basic fact is that in a lot of cases, the only way to validate and fix the quality of these data sets is to push them out the door and see what happens when everyone starts poking and prodding at them, because not only can’t you hire, train and manage a testing team large enough to deal with data sets this large in a rational way, doing the testing almost requires an infinitely large set of testers, each with intimate knowledge of some small subset of the data.

Which, if you think about it, only exists in one place: your user base. 

So you can gripe all you want at Apple for the quality of the maps they released. I’m sure they knew about it. Just like we could know that list of 50 million email addresses was “clean”, until you actually start pushing it out the door and having it interact with the real world, you have no clue out “good” it is. 

So if you’re one of those people complaining about the quality of the maps — stop and ask yourself how you would have done the testing better to avoid it. Not just for that little part you know, but on a global basis at a local level. Because that’s what testing that data set needs. 

Good luck. you’ll need it.

Why I Think the iMac Pro is Coming Next Year — Josh Centers:

I am convinced that Apple will release a retina iMac in late 2013, and chances are, it will be a “Pro” model to replace the Mac Pro.

Some interesting speculation on where the Apple product lines might head and what retina displays mean for them. 

I keep thinking that there are a number of pieces of Apple’s product line due or overdue for the classic Jonathan Ive “I think we need to rethink how we do this” treatment: the iMac hasn’t had a significant redesign in a good while. Ditto the Mini. Ditto (except for the move to Thunderbolt) the Cinema display. 

The realities of the market Apple is selling this stuff into has changed significantly, too. More and more of us have moved to a “laptop first, laptop only” relationship with our computers. The market for the Mac Pro continues to thin out and it’s become a true niche device for serious high end graphic/video/photo geeks and developers who need it’s power to drive Xcode. 

The mini has split it’s audience into people who need/want a desktop to supplement their laptop and people who use it to drive their home media systems. It’s also used by some (as are iMacs) instead of Mac Pros, because in reality, the Mini and iMac more than serves the needs that used to require a Mac Pro for many users. 

Apple has unofficially said the’ll have a replacement for the Mac Pro out in 2013. It’s fairly safe to assume there’ll be a major move into retina displays, and so we ought to see the iMac revamped, and the Displays, and…. 

I keep wondering if it really makes sense for Apple to manage all of these products? Especially if you start thinking that it’s likely they’ll do both a Retina iMac and a non-Retina iMac to keep the pricing of low-end units accessible, it seems to me the product line starts to get — complicated. 

If I tried to think this through the way I’d expect Apple to, I start thinking it’s time to blow it all up and do it differently.

Modularize.

You start with the Cinema Display. Apple currently does three: the 27″ display, the 27″ display with attached computer (aka iMac), and a 21″ display with attached computer. 

So how about 24″ Display, 24″ retina display and 27″ Retina display? 

And then if you want, attach a computer to it? Instead of doing an iMac, a Mini and a Mac Pro, you do a CPU unit that can either attach onto a display and act as a consolidated computer, or run headless. And you do a consumer class version and a “mac pro” high end version. One form factor, multiple price/performance points. 

To support the data needs that some use the Mac Pro for, you also build a Data unit. It connects to the CPU unit via thunderbolt, and you can mix and match up to, say,  six or eight drives into it. It’ll support various raid configurations, and we can all is “mini iSan” or something.

With USB 3.0, bluetooth, Thunderbolt and Apple’s modular power setup and magic ability to create connectors, they could create a set of pieces that give them a lot of flexibility to sell standard configurations that hit many different price and performance points. Standard configurations can ship with pieces already mated together.  

And it’d give both Apple and its customers the ability to upgrade a given piece of the system when they want, where with the iMac today, if you want a faster CPU, you have to buy a new monitor with it. 

So if I were running the show (hah!), I’d do the next generation of hardware differently. Think modular. Think flexible. And by doing so, you’re actually making your life managing the product life of all of the product lines much simpler…. 

Apple Outsider » Technology vs. Utility:

As ReadWriteWeb’s Brian Proffitt explained last week, omitting NFC is a conscious decision that can be easily reversed in the future. But unlike earlier missing iOS features like copy-and-paste, multitasking, and yes, an SDK, NFC is far from a no-brainer addition to Apple’s flagship product. Critics are stuck in the usual mud of tracking technology rather than utility.

It’s no coincidence that the “Tech Specs” link atop apple.com/iphone is dead last. Apple’s best marketing has always been about what a product does, not what it has. Forget MHz and GB and mAh — how much faster does it launch apps? Play games? Snap pictures? Load web pages? How many hours of video and talk time? These are things that anyone can not only understand, but appreciate.

Behold the NFC issue. What can people do with it today? All we hear is what they should be able to do with it someday. Search the web for “near field communication” — the 2010 articles read exactly like the 2012 articles. And boy are they wordy.

“What can you do with it today?” 

That’s the rub. NFC is one of those technologies that requires a lot of moving parts. It’s not just something you stick in a phone, it’s something that requires support by credit card processors  to support transactions and retailers who need to update their processing terminals. Just sticking it in a phone is a recipe for disaster, and Apple doesn’t do disaster’s it can avoid. 

And while NFC would be something Apple would build support into IOS for, I think it’s a technology crying for a developer API, and so it’s very unlikely Apple’s going to surprise the universe shipping it in a phone without advance warning to the developers. Imagine the joy among the developer community if iPhone 5 shipped with NFC, IOS 6 has a surprise API supporting it, and the only apps ready to use it were Apple’s and a half dozen key “special” partner companies? 

No, when Apple does NFC (and I think it’s likely they will), NFC ought to be a WWDC announcement, with Apple coming out on stage and with their partners out doing the infrastructure showing up and everyone showing just how great NFC is going to be, once it ships in IO7 (or 8) on the iPhone 5S, and, of course, “here’s why you need to get going on your NFC support in your apps today!” as part of the show.

That give the partners (Visa, amex, Discover, etc) 6-9 months to build out the terminal infrastructure and developers a chunk of time to build the apps, and everyone some time to make sure everything works together and is ready to go. You’re not going to build an NFC infrastructure out into the retail market in secret, the universe is going to see it coming. So I can’t see Apple trying. Instead, it’s going to take the card processors to take a lead to build out the retail side of this, and then you’ll likely see both Apple and Android build it into their phones and OSes. One platform or the other might get a head start here as a preferred partner, maybe. 

But NFC isn’t the kind of technology that you can stick in a phone, do the “look under your chair, everyone gets a car!” surprise with it, and expect it to succeed. It can’t stand alone, and the infrastructure won’t magically appear. And as of today, it doesn’t exist here in the U.S. 

So NFC is this year’s “we want LTE” — the rallying cry of the geeks who expect a technology to ship years before the infrastructure needed to make it usable in any real way is actually available to support those who want to use it… 

Now Imagine If Amazon Had Bought Palm And WebOS – SplatF:

So here’s an interesting exercise: Imagine if Amazon had acquired Palm and WebOS instead of HP. While WebOS and HP’s TouchPad tablet were ultimately failures — and the deal timing doesn’t really work — it may have resulted in a more interesting partnership and more successful products.

What WebOS did well is exactly what Amazon’s Kindle Fire needs: A beautiful, clever interface, second only to Apple’s. (And even better than iOS in some ways.) Combined with Amazon’s expertise in e-commerce, digital media, and its aggressive pricing, a Kindle TouchPad might be an even more compelling device than what Amazon has built on its own.

There are some major problems with this idea, of course. Amazon’s app ecosystem mostly exists because companies are already developing for Android. Building the Kindle Fire around WebOS would have meant far fewer apps, at least in the short-term. Or perhaps the WebOS team could have remade its user interface for an Android-based tablet, but who knows how long that would have taken or if it would have been any good. (Not to mention any economic or logistical problems with this combination.)

But, still, an interesting idea! Jeff Bezos clearly cares about becoming a great tablet maker, and Palm’s team — led by ex-Apple executive (and now Amazon board member!) Jon Rubinstein — might have helped. It’s hard to imagine Amazon blowing the Palm acquisition worse than HP did. It might have even been a great combination.

The app ecosystem isn’t that big a deal. you could take it a couple of ways. If Amazon has bought Palm, they would have had Palm’s partnering and business development team, which was pretty darn awesome. You want to convince people to write apps for a platform? First, you need a team who knows how to make those connections and sell the opportunity. And then you need an opportunity they can sell. “Hey, this device will be plastered on the front page of Amazon.com for the next two years at this price point, and we’re going to push it hard into the hands of everyone we can get it in front of. And if you commit to shipping this, we’ll make sure your app gets a month of favored placement in the catalog during the holiday season and you can demo it at the launch announcement”.  If you need to, for key apps you can sweeten the deal with anything from outright subsidies (“we’ll hire two developers for three months”), marketing and publicity, any number of things. 

Amazon’s story was easier being on Android to some degree, but this is a very manageable situation if you have the right people and management commitment. 

Or Amazon could have built an Android compatibility layer into a WebOS-based device. Quite technically possible for the right teams.

Or what I’d most likely have done in their shoes: take the webOS user-visible interface components and port them to Android to replace the Android versions. Basically throw out the underlying technology and run the webSO front end on Android. The bad news (for Palm/webOS at least) would be that Amazon wouldn’t have needed a huge chunk of Palm to do that, it only would have needed to bring over a 100-150 people, more or less. Which is, from what I can see, about the size of the webOS GBU under HP today, so the end result would have been about the same, at least as far as leaving dead bodies on the side of the road during the death march… 

And if Amazon DID investigate buying Palm back at that time (and I honestly have no idea one way or another), that’d be the thing that killed that deal. Palm at that time was only interested in a buyer that would keep them together and let them continue to try to build the product. “Parting out” the company was only an option if they couldn’t find a buyer that’d continue the operation. HP would and did. A deal where someone bought Palm and then laid off 2/3 of the company wouldn’t have been on Ruby’s A or B lists (and there were — rumors say — a number of players looking to buy Palm for the patents and throw all of webOS and it’s people into the recycling bin…. Depending on what rumors you heard, ALL of the offers other than HP were that kind of deal. I know that’s what I was expecting…)

There are rumors (and again, I DO NOT KNOW. I wasn’t in the meetings, if there were any) that Amazon investigated buying  webOS after Leo blew it up and HP was looking at options (and exits). And that Amazon ended up walking away from it because the costs of operating the organization was way beyond what they considered affordable because of the costs associated to supporting the cloud aspects of webOS. So it’s possible Amazon kicked the tires on this twice, but if they did, the first time, it probably was a deal Palm wasn’t interested in, and the second time, the price tag made webOS too expensive for them to take on. 

So I think webOS on Android on Fire (so to speak) was definitely something that could have been considered and could have given Amazon some nice options to work with, but the cost of making ti happen would have been way beyond what it would have made sense to pay to get it.