Skip to main content

The fallacy that WP7 is immune from the race to the bottom

People left and right are claiming that if Nokia had chosen Android, they would be one vendor amongst many competing on thinner and thinner margins, while WP7 somehow isolates them for that. As far as I can tell, that is now commonly accepted as truth. It is amusing how a fallacy turns into "common sense" when repeated enough times.

In reality, of course, people don't buy operating systems. They buy phones, and they would not buy a more expensive phone if a cheaper one offered the same capabilities given comparable manufacture quality and design. This is such a simple and fundamental truth that it is almost unbelievable that it is ignored.

Apple is always used as a counter-example, but in reality an unlocked iPhone costs about the same as any other high-end smartphone with comparable parameters. Granted, people will pay more for good design or even just a fancy logo, but the name of the OS running in the phone hardly even enters the equation.  In particular the notion that consumers will pay premium specifically for WP7 is frankly laughable.

Of course there are other factors: the brand name of the manufacturer, the quality of the app ecosystem and so on. Those are valid considerations, except that most of those currently point towards an advantage for Android, not the other way around.

So, specifically the fallacy is this: while it is commonly accepted that Android is "comparable", if not "better" than WP7, at the same time it is also claimed that WP7 will bring in higher premiums.

Nokia can manufacture some pretty good phone hardware, so they deserve high margins, but the sad reality is they are in the same race to the bottom as everybody else, including Apple, and one day the license cost of WP7 (compared to free Android and IOS) might end up being a huge problem.

That is my objective evaluation of the situation, but it doesn't mean I like it. We will end up getting crappier and crappier product as a result, just as today it is almost impossible to buy a high quality PC regardless of the price.

Comments

Popular posts from this blog

How to speed up a micro-benchmark 300x

How to speed up a ubenchmark 300x Static Hermes: How to Speed Up a Micro-benchmark by 300x Without Cheating This is the first of a series of light blog posts about Static Hermes, covering topics that I find interesting or amusing. It is not intended to be a systematic introduction to Static Hermes design.Consider it more like a backstage pass to the quirks, features, and “aha!” moments that make Static Hermes unique. If you’re not familiar with Static Hermes, it’s an evolving project we’re working on to explore the confluence of static typing and JavaScript. It is work in progress, but we’re excited about the possibilities it opens up for performance improvements and more. For more background: Tweet with the slide deck of the Static Hermes announcement Previous talk about Hermes Contents: Meet interp-dispatch.js Let’s Run It! Static Hermes with Untyped Code Helping the Compiler Other Ways to Help the Compiler Some Observations Revisiting The Origina

You Don't Like Google's Go Because You Are Small

When you look at Google's presentations about Go, they are not shy about it. Go is about very smart people at Google solving very BIG problems. They know best. If you don't like Go, then you are small and are solving small problems. If you were big (or smart), you would surely like it. For example, you might naively think that printing the greater of two numbers should be as simple as std::cout << max(b(),c()) That is because you think small. What you really should want is: t1 := b() if t2 := c(); t1 < t2 { t1 = t2 } fmt.Print( t1 ) Isn't it much better? We didn't have to type all those extra semicolons that were killing productivity before. If you don't like it, you are small. If you wanted to extract an attribute of an optional parameter, you may be used to typing something like: a = p ? p->a : 0; or even: a = p && p->a You just make me sad because obviously what you really want is: a = 0 if p != nil { a = p->

Apple2TC: an Apple II Binary to C Decompiler - Part 7, Using The IR

 This is part 7 in a series of posts describing Apple2TC.  The start is in  Part 1 . Part 6 introduced our SSA-based Intermediate Representation. In this part we look at a running IR example and how it is transformed by our decompiler pipeline. Introducing The Example To demonstrate the utility of our IR, we have devised a slightly contrived example that nevertheless illustrates challenges encountered in real code.  The source of the example can be seen here:  https://github.com/tmikov/apple2tc/blob/master/blog/part6/ex.s . We assembled it with a6502: a6502 ex.s ex.b33 and disassembled it: apple2tc ex.b33 --asm > ex.lst Producing the following listing: /*0300*/ TSX /*0301*/ INX /*0302*/ INX /*0303*/ LDY M_0101,X ; $0101 /*0306*/ INY /*0307*/ STY M_90 ; $0090 /*0309*/ LDA M_91 ; $0091 /*030B*/ STA M_92 ; $0092 /*030D*/ L