Monday
Clear skies and California-like weather make Monday an unusual day in Beijing. Young women carry umbrellas for shade. Beijing is hot in the summer, cold in the winter, but this week starts with sunshine and pleasant temperatures.
The crush of numbers in Beijing is immediately obvious. Millions of people on their way to work. Packed buses, nose to tail, occupy a quarter of the road space. Taxis make up most of the rest. From my hotel room on the 18th floor I could see the frequent arrival of the elevated train bringing even more people into Beijing. There must be regulation of when delivery trucks are allowed to operate, since very few are visible.
Most of the commuters of Beijing are on their way to office or service jobs. Dress is informal, but not shabby. Neither is it stylish. About one out of 100 women wear something with real style, and some anti-style is evident in the form of flesh toned ankle socks worn to get maximum mileage out of the very flimsy-looking shoes most women are wearing. Men wear short sleeved shirts, unremarkable trousers, cheap shoes. Beijing is not about the clothes, perhaps due to the harsh climate.
Street life and food
One measure of China's emergence from ideological control over the minutia of life is the vibrant street life of a city like Beijing. Apartments are small, and life is lived out in the city. Middle aged women play cards on folding tables on the sidewalk. Emotive players bang the pieces of a Chinese chess game on boards resting on deliverymen's tricycles parked on apartment forecourts. Shirtless construction workers escape their pre-fab metal dormitories to sit in the shade of a tree on the street. There is a wide range of “normal” behavior on the street. Police do not break up the card game just because it is on a busy sidewalk.
Restaurants line the main boulevards, their shopfronts protruding from office buildings, brightly painted, festooned with lanterns. Many of the restaurants have large windows, and you can see the crowd (or lack of it) inside.
Young couples, many probably from nearby universities, and larger groups of work colleagues make up most of the crowd where I ate. The operation is large-scale, with about 200 boistrous diners seated, served by a wait staff that takes order and delivers food as it is ready, checking off their delivery against a carbon copy of the order left at the table. 600ml bottles of beer are delivered to the table in wooden totes.
Competition among restaurants must be fierce: New restaurants, closed restaurants, and restaurants under renovation are all in evidence. The ingredients and preparation at the restaurant I describe here are top quality: Green beans of the same not undercooked yet not mushy texture that really good French bistros achieve. “Streaky pork” with perfect taste, texture, and temperature throughout a thick slab of what amounts to fat fried in fat. It could have been a greasy mess, but the thin slices held together just right, and tasted something like bacon made by angels.
The food is not innovative. Everything on this menu appears on similar menus in hundreds, perhaps thousands, of other restaurants in Beijing. But, like traditional restaurants in Europe, correct execution of the local food idiom is life or death for an establishment, so quality is consistently high, even when operating at a frantic pace. For a foreigner, it's an amazing treat to experience food preparation that is so honed to perfection.
It is even more amazing to ponder the fact that the food culture and street life of Beijing have developed to the present scale only since liberalization began. Hundreds of years of tradition sprang back, ready to serve millions of meals every night, as if never interrupted.
Scale and density
China is on a wild ride of urbanization, economic growth, liberalization, demographic shift, and international influence. Scale and density make each element of China's transformation more intense, and potentially more calamitous if it goes wrong, than anything that happens in the U.S. or Europe. Density has benefits in that Chinese cities have the critical mass for vibrant street life that is hard to achieve in the U.S. In Beijing, even far from the city center, the city is a dense mix of offices, residences, restaurants, and shops.
Density and scale are also challenges in themselves. It is remarkable that the sea of humanity sloshing around Beijing's rush hour all have workplaces to get to and jobs to do – many of them apparently office jobs, in a country that is perceived as being all about manufacturing. The fact that what are, in local terms, middle class jobs and living arrangements, have been scaled up so quickly, is an optimistic sign.
Beijing is not merely a government town. The local economy outweighs the government in a sharp contrast with Washington D.C. While there must be the Chinese equivalent of beltway bandits among the office buildings of Beijing, they are not so obvious as they are around D.C., where businesses that sell to the private-sector look out of place among the government and its numerous camp followers and outfitters.
Brown again
By Wednesday, Bejing has gone from mostly sunny and a little brown and hazy in the distance, to the typical cut-it-with-a-knife Beijing smog. It will take a heroic effort to keep the 16 days of Olympic games, a year from now, clear enough not to cement Bejing's reputation for smog. China starts up new coal-fired power plants about as often as Starbucks opens a coffee shop.
China is living through a series of inflection points, each with am amplitude five times larger than what would happen in Europe or the U.S. Thus far, China has managed the ride with impressive balance and results that are worth going to see in person.
Because the perception of China in the rest of the world is behind the times, the Olympics are likely to be quite an education for the people watching on TV. They will see amazing achievements of development, and they will see normalcy in the lives of Chinese people. Hopefully they will understand the importance of China not in terms of trade surplus or diplomacy, but in terms of hundreds of millions of people emerging into the modern world – a feat that some held was impossible, and some still deny can continue.
Sunday, August 26, 2007
Another Week in Beijing
Posted by
Zigurd
at
7:00 AM
0
comments
Labels: August, Beijing, economy, growth, people, restaurants, street life, traffic
Tuesday, July 10, 2007
iPhone: Analyzing the Industry Reaction
Toss a pebble into a pond and watch the ripples. In the case of the iPhone, it's more like a grenade was tossed into the pond full of typical telecom industry punditry. All species of industry assumptions are now floating on their sides, stunned, on the surface of the pond. Let's fillet some and see what's inside:
Don't say it's the new iPod
The principal mistake made in analyzing the iPhone is the being phone-centric. In fact, the iPhone is the new iPod. It is the video iPod. It is the new iPod user interface. It is the WiFi iPod. It is the first of many new iPods, some of which won't be mobile phones. If you had been thinking “How many people really want a $600 phone from Apple?” think again: Apple didn't sell 500,000 to perhaps 700,000 phones in the first weekend. They sold that many high-end iPods, too. This is the factor missing from most projections that will enable Apple to safely make their numbers for the iPhone.
Telecom industry people will have to learn to look at the iPhone as an iPod first. They don't look at the Nokia N95 as a video camera. Nor do they look at a Blackberry as a PDA. This is something entirely new, and it will affect the way future iPhones are formulated.
3G has value
Some regret has been expressed over iPhone not having 3G. The real reason for the tut-tutting about no 3G in the iPhone is that the telecom industry was hoping iPhone would be 3G's killer app. The reality is the mobile data network is a backstop to WiFi until speeds are up and pricing is down. It is possible the gap will never be closed. 3G has limited value and significant down-side in higher hardware cost and lower battery life.
Some iPhone customers, mostly pundits that don't see their phone bill, have griped about lack of 3G. But more than balancing that out has been buzz about how to use an iPhone with a cheap prepaid account, or no mobile account at all.
Where is 3G in Apple's priority list? It's below taking the iPhone down-market, so raising costs by adding 3G, except at the top of the model range, is not likely to be part of the plan.
Carrier-driven product management works
iPhone was defined within Apple, with the goal in mind of transferring Apple's success in media players to the mobile phone market. It wasn't designed for the existing network. It wasn't designed for a carrier's ARPU strategy. It wasn't designed to provide a delivery vehicle for a new section of the walled garden. iPhone was subject to none of the industry influences that go into “normal” phones. And yet the iPhone is a huge boon to AT&T, with half of iPhone customers switching to AT&T. Will other carriers, especially second tier carriers that don't have the resources to do more than follow the lead of first tier carriers' mobile commerce and data strategies, add more products that are not defined by their internal product management initiatives? Probably not! But they should consider that the more they tighten their grip, the more churned customers slip through their fingers.
It competes against smartphones
Name a smartphone product that could sell 700,000 units at launch. How many of Apple's 700,000 first-weekend customers compared iPhone against a smartphone? Still, many futile efforts will now be launched to turn smartphones into iKlones. Now you know how to spot the next set of industry train wrecks. Ironically, Nokia, which has the best chance of actually making a competitor to iPhone is probably trapped by the fact the S60 UI is the best among smartphone UIs, when abandoning the smartphone UI is the only way to really compete with iPhone.
The rumors of a Microsoft “Zune Phone” would be credible and welcomed, if only Zune hadn't flopped badly enough to damage anything called a Zune Phone. A Zune Phone would break from the smartphone mold and it would actually be a good idea to make one. Or, for that matter, to put MSN Messenger into a Zune, with a Zune-ish UI. Anyone willing to put away the PDA heritage in the museum where it belongs has a good chance of success.
All bow before mobile unit volume
One reason why mobile telephony is so fascinating is the amazing volume of phones being sold. A billion per year and growing, and not all developed-world markets are saturated. This makes phones, and the components that go into phones – the systems-on-a-chip, or SoCs – the most important computing devices today.
Because of the volume of mobile phones being sold, it was assumed that when mobile phones started to incorporate music players it would spell the end of standalone music players. What follows from this prediction is that iPhone is a defensive product – a shift to the winning mobile platform and away from a standalone iPod.
But, while everyone else still must bow before mobile unit volume, Apple now sells enough iPods that mobile unit volume cannot overwhelm the iPod. Apple isn't making an iPhone as a defensive measure. In fact, Apple has flipped this around to where Apple is selling phones because they are part of a new-generation iPod.
The game will really be on when iChat is added to the mix. Then Apple will be adding new modes of communication and new communications applications to their phone products.
Monday, June 18, 2007
JavaFX'plained
Previously I gave an overview of Sun's present condition and prospects. Sun's recent announcement of JavaFX provides an illustration of how well Sun is doing staying on the right course.
First, remember to steal the good ideas
The use of one brand to cover disparate products is one of those bad ideas people really shouldn't steal from Microsoft. What the hell was COM, anyway? Sun had their own misadventure with one confusing name for a variety of technologies: “Beans.” Netbeans, Java Beans, Enterprise Java Beans, this beans, that beans. The meaning was obscure from the start and it turned into a semantic fog as things labeled “Beans” diverged from each other and from their original technologies. JavaFX carries on this proud tradition: In part, it is a product that was formerly called F3, or Form Follows Function. What a fine name. Let's replace it.
In part, JavaFX is the mobile Java and OS technologies acquired from SavaJe (“sava J?”, “savage?”) which is a stinky name that ought to be replaced – but not by the same one that will only confuse people. Now it's all called JavaFX. Alles klar?
JavaFX Script
The hard part about the discipline of focus is that people keep tempting you to chase competitive responses. This temptation is high right now, with Adobe attacking Sun on the server side with Flex, and Microsoft attacking Adobe Flash and server-side Java with Silverlight. I'll keep this brief lest anyone mistake me for a Web application guru: While F3 is a great product, it isn't enough to make Sun a key player in client scripting technology. Various Javascript/AJAX tools – many of which complement server-side Java - and Adobe Flash rule this area now. Microsoft has the chops to make a run at it, and Silverlight looks like a credible attempt. Why tilt at this windmill?
There are reasons to doubt JavaFX Script is up to the task: For one thing, it requires the full Java runtime - the same hurdle that makes Flash a more attractive alternative in many cases. It also relies on Java Web Start, a little-used and somewhat cumbersome technology for launching Java applications from Web pages. Silverlight takes a more direct approach to the runtime problem, shrinking the .NET runtime to where it can be deployed as a browser plug-in that is comparable in size to the Flash plugin.
There are numerous doubts about JavaFX Script's future: Can Sun apply the resources to make JavaFX competitive? It that possible without rearchitecting JavaFX Script? Is there a need for a Java technology other than, say, GWTs for creating browser-based rich interfaces?
The announcement of JavaFX Script looks like Sun gave in to the me-too temptation, and took an interesting but underdeveloped technology, dragged it half cooked on stage at a developer conference, and discovered that most of the audience's reaction was “Huh?”
It will take a marvel of cross-project coordination to make JavaFX Script work: A scale-able JRE, UI creation tools, improving on Web Start for deployment, etc., all going into the teeth of better-funded efforts at Microsoft and Adobe.
JavaFX Mobile
In addition to the general confusion that comes from using the same name for two different things, JavaFX's chances in Web applications could drag down JavaFX Mobile.
JavaFX Mobile is the re-branding of assets acquired from SavaJe. These assets include an operating system with roots in the Bell Labs Inferno OS, an implementation of JavaSE for mobile devices, a mobile phone user interface, and a suite of applications. Why not call it “JavaSE Mobile” or “Java Mobile OS?” That would be recognizable, descriptive, attention-grabbing, unambiguous. Nah.
Sun has a task ahead of it: Buying the assets of a failed startup with a pre-market product is dicey because the product isn't in saleable condition. Sun has to quickly diagnose what went wrong with SavaJe and make the right adjustments. This may include a substantial investment in product development on top of the cost of purchasing the assets. Purchased assets are seldom aligned with the priorities of potential go-to-market partners, so a purchase can look disappointingly off-target just as new resources need to be committed to it.
SavaJe took the most brittle strategy possible and broke their $120M VC pick on it. That doesn't make them stupid: A VC funded company's task is to pursue the opportunity the investors want pursued, even if it is riskier than what the founders might think is the optimal balance of risk and return. SavaJe pursued top-tier mobile OEMs with the proposition that Java SE on a minimal embedded OS from the same vendor makes for a compelling modern platform for mobile handsets.
Handset OSs are due for a shake-up. The winner, by default, for an off-the-shelf mobile software stack is Windows Mobile. Palm used to contend for this business but has failed to update their OS for too long now. And while mobile software took approximately twice the usual number of versions for Microsoft to get it right enough, Windows mobile is now a low-risk path to market for ODMs making smartphone platforms.
Still, there is a huge opening for other mobile OSs: Microsoft doesn't “get” OEM requirements: If you want a feature, they will add it to the list. Thanks for your input. Windows Mobile is too resource-heavy, and the license is too expensive for mass-market phones. Microsoft is a competitive threat to any OEM with an eye on the enterprise mobile and unified communications business. There are plenty of reasons the market needs an independent technology provider that isn't taking a vertically integrated approach.
So why did SavaJe fail? The short answer is that they failed to provide sufficiently compelling product and value to crack the very limited number of target customers they were aiming for. The SavaJe UI was no great shakes. From looking at it, and from what it did, it was hard to discern the benefit of a new OS and a Java application layer. In fact, the newness of the OS, and the need to buy and interface compulsory components like Bluetooth, dragged down SavaJe's ability to make use of Java as a tool for creating a superior user experience. Inner beauty doesn't put software on handsets.
On top of that, SavaJe's founders had an attachment to doing their own operating system. It's what they did at Bell Labs. It's what they understood best. And while the decision to use Java (instead of a purpose-built managed language system as in Inferno) was the correct one, the OS consumed resources and mindshare that could have been better focused.
There are other examples of attempts at mobile software stacks that lacked a reason to exist: Pollex, based in Beijing, tried the “it's cheaper” approach to the lower and middle-tier handset makers, and ended up in an asset sale to a chip maker that is re-purposing those assets under the heading “it's zero-cost.”
Which leads to one of the big questions facing Sun: double down on the operating system bet, or cut your losses and go with Linux as a mobile operating system, or they could go batshit crazy and convince themselves that if Apple could turn OS X into a mobile OS, Sun could do the same to Solaris. Frightening that that is even plausible enough to enumerate as a possibility.
Another big question Sun faces is: How to forge the SavaJe applications suite into a compelling user experience, and for what purpose? Look at the lesson of Pollex: Is SavaJe anything more than Pollex in Java? Sun has to come up with something better than “Series 60 is getting old.” Java, by itself, can't sell it. The story has to go something like “JavaFX Mobile solved the incredibly painful _______ problem for me, and what's more, it was a great software development experience customizing it because of Java.” If they can't fill in that blank, better to stop and rethink it.
Last, and not least, Sun faces the question: What is the market insertion strategy? There are only a handful of tier-1 mobile OEMs. Even if Sun comes up with an amazing mobile user experience, what makes it so compelling that a mobile OEM would give up their own differentiation through user interface in order to adopt Sun's? As a high-cost technology provider that can't afford to be as patient as Microsoft, it will be difficult for Sun to avoid the same logic that drove SavaJe into the long shot approach of targeting tier-1 mobile handset OEMs.
Sun has opened two fronts against adversaries that can apply more resources. The better decision would have been to pick one and go for a decisive win.
Friday, June 01, 2007
A Week in Beijing
Prelude
The Chinese consulate's visa office is efficient. It has to be, since it is thronged from the moment it opens in the morning. A display above the row of windows shows a queue of the next several applicants' numbers and assigned windows, so you know the optimal time to get up and and stand at the assigned window. My wait time was short, even though the waiting area was full. Same-day service (about 4 hours, really) costs just a little more, and a kiosk in the waiting room enables you to check the status of your visa processing by scanning the bar code on your receipt. They seem to beat their estimated completion time, so show up a little early for pick up and check at the kiosk.
United Airlines still uses the East German service model: The PA system blasts your ears if you are unlucky enough to use their “entertainment” system when the safety announcements are made. The seats are packed-in, making it difficult to use a laptop. The Boeing 737 is dingy, and the lavatories smelly. Service is sparse and unfriendly: If you ask what is in the snack boxes, you are told to look it up in the magazine. There are worse airlines, but not by much.
The plane was delayed at departure due to a broken seat. More seriously, the smell of burning electrical insulation filled the cabin in the middle of the flight. It was serious enough to cause the flight attendants to grab fire extinguishers, and for passengers to get out of their seats to try to assess the seriousness of situation themselves.
This time, United got me to my connecting flight, barely. The 747 out of SFO was an improvement over the flight from Boston. The service was less customer-hostile. In-ear, noise-isolating headphones and a few hours of sleep on this leg of the flight were key to arriving Monday afternoon in good enough shape to push through to evening in Beijing without falling asleep too early. The 12 hour time difference was easier to adjust to than the 6 hour difference to Europe.
What it's like to be illiterate
The biggest pucker-factor in traveling to China is the fact that, if you have not put in the considerable effort to learn a few hundred Chinese characters at a minimum, you are illiterate. On top of that, Chinese pronunciation isn't easy, and the locals are not used to non-native speakers mangling their language. Nobody will understand what you are staying if you try to use a phrasebook. If you get lost, you are screwed.
You must have your hotel's address and phone number printed in Chinese to show the taxi driver. At the airport in Beijing, walk past the touts for gypsy cabs and go straight to the efficiently-run official taxi line. The attendant will make sure the driver understands where he is to go.
Even though people are getting their visas for travel to China as fast as the consulate can process them, the scale of Beijing means that visitors are swallowed up. The hotel clerk will speak enough English to get you checked in. That's it. You are well and truly in China, and most of it isn't labeled in English. Signs are undecipherable to you, and therefore untranslatable, even if you had a dictionary.
Hotels are plentiful, moderately priced, and (at least the better moderately priced ones) clean. Since it is nice to have a hot shower and BBC news in a place where you can't read and nobody understands what you are saying, I would not economize on the hotel too much. Food, however, is another matter. You will be happier in a local noodle shop than in the hotel restaurant. The only substandard food experience I found in Beijing was at a hotel restaurant where the potstickers looked as if they came straight out of the freezer and into the Fryalator. Noodles are to Beijing what bread is to Paris. The locals will gawk at you, and you will have to point at what you want, but it's worth it.
Smog
Beijing is often cloaked in smog. Monday afternoon combined smog with a low overcast. Eventually it rained. The evening was science-fiction gloomy, illuminated by incomprehensible shop signs reflected in the wet pavement of the main road through the Haidan district. Disappointingly, the evening did not include anyone saying “He say you blade runner.”
Tuesday
The rain failed to clear the smog, and a pale yellowish-browish haze created a bubble of visibility about three blocks in radius.
China, as a relatively open society in practical terms - that is, where people can choose their education and employment - is less than 25 years old. Everything is new here. So, although liberalization in China predates the fall of the Berlin Wall, it started from a far more closed society, and with a far larger population.
The fast pace and massive scale of development in China gives rise to startling realizations: Although Beijing is full of cars, people measure their driving experience in thousands of miles, not years. Almost everyone working in software is young, and they look younger.
While not readily visible in Beijing, there are aspects of China that remain Dickensian in their vividness: A news story about an orphanage for deaf-mutes renting their children to pickpocket rings, and another about a horrific industrial accident in a steel mill, for example.
Big, and getting bigger faster and faster
China consumes half the world's production of concrete and one third of the steel. It is said half the construction cranes in the world are in China. Maybe more. Beijing is a mid-rise city, perhaps due to an aversion to having the Imperial Palace fenced in by skyscrapers. Instead, 15-30 story buildings line the boulevards in all directions for miles. Seldom is a new apartment building a singleton. More likely four, or six towers cluster together.
Beijing is not a tidy north European city. There are plenty of older, down at the heels apartment buildings. Petty theft is a common topic even in English language newspapers. But brief strolls away from the main road, through the back streets where apartments tower behind the front rank of commercial buildings found little misery or hooliganism.
Construction workers live on-site, in prefabricated two and three story metal dormitories. These were much in evidence in the Haidan district since a new subway line is under construction.
China is young
Young people, often walking hand in hand, were typical of the people on the street. Modest shops catering to the locals are in the side streets, and, often enough, on the main road, too. The shopkeepers were typically cheery, often chatting with friends or customers in front of the the usually small shops. The scale of Beijing ensures tourist shops cluster near the Imperial Palace and a couple of nightclub districts. Everyplace else has to make a go of it based on the local people's custom.
The defining characteristic of Beijing is youth and easy informality. People are neither wearing rags nor do they stretch to look more “proper” than they need to. Work attire at technology companies, where pay is a bit higher than average, is remarkable for being mostly the same as what coders everywhere wear. Workmen loudly go about constructing the shop next door to a restaurant, and diners are unfazed by the noise. Beijing is about getting on with commerce.
While a city this large cannot be dominated by a building, the Olympics are on everyone's mind. Much of the modernization of Beijing was driven by the deadline of the Olympics and the people of Beijing are genuinely excited that the world will see what their city has become.
In 25 years, hundreds of square miles of overcrowded hutongs have been transformed into a modern cityscape, even as the city absorbed millions of migrants from the countryside. Millions of trees have been planted in time to grow large before the Games. Hundreds of miles of new expressways were built, and were filled with cars in only the last decade. If anyone still thinks China is a cluster of industrial parks feeding the Wal Mart supply chain, they will be stunned to see Beijing.
Mobile culture in Beijing
The Chinese have phones. Many of them have nicer and more expensive phones than people at the corresponding income level in other countries, indicating that the mobile phone attracts a larger share of income.
The typical mobile phone shop, or department in an electronics shop, puts the high-end Nokias and SonyEricssons up front. The mainstay phones are little different from those in the U.S., with color LCDs and the usual set of features, a bit trailing-edge, with an emphasis on low price. Super-low-end phones are available, with monochrome displays, but not all that common. As in the U.S., most phones are GSM, with a large minority of CDMA phones.
I have seen the future of electric vehicles
The government makes is hard to get a registration for a motorcycle or scooter, so these are rare on the streets of Beijing. Bicycles are still commonplace, but the typical Beijing commuter takes the bus or the subway. Taxis are ubiquitous, and there are enough people who can afford cars to clog the roads and make it faster to bike during rush hour. The main boulevards have frontage roads that are for parking and for bicycle traffic.
But the real star of Beijing traffic is the e-bike. An e-bike is a bicycle with a 250 watt electric motor in the rear hub, and a battery pack on the down-tube or behind the seat-tube. The batteries are removable for charging at home or at the office, and pedals ensure that you cannot be stranded by a faulty charger or unexpected side trips that exceed the range of the batteries. The look is somewhere between that of a bike and a very light moped. Some come with more powerful motors and larger batteries, and look like scooters.
The popularity of e-bikes is exploding. They glide along at about the top speed of a bicyclist, and because they can keep that up consistently, they are the fastest way to go when traffic is heavy. They are incredibly energy-efficient, and cost about US$300 – affordable for most Beijing commuters.
The impetus to create e-bike products is the limitation on motorized scooter and motorcycle registrations, so this is a market that is rapidly evolving in China. Outside China, Giant and a few other bicycle OEMs sell e-bikes in the U.S., but these products are expensive and have not found a customer base. Ad hoc importers, which you can find on eBay, offer China domestic-market models but at a steep mark-up.
The knock on e-bikes is that the lead acid batteries must be replaced every two years – more often than car batteries. While lead acid batteries have been successfully recycled for decades, there have also been numerous cases of poor practice in developing-world recycling plants. However, if proper recycling can be assured, the e-bike could become a very beneficial global phenomenon.
Coffee in Beijing
Coffee is foreign. Coffee is expensive. “Coffee shops” often don't “get” coffee. But sometimes, you need coffee. The strangest food experience I found was in a “coffee shop” where I ordered a coffee, which was passable, and a “puff pastry” that turned out to be a blob of deviled ham on a toaster waffle.
The Coffee Time chain of coffee shops is very good, however. Excellent espresso drinks and gelati in the Italian style. But the prices are high enough to keep the locals mostly out.
As with many other things in China, coffee and chain restaurants are new and still being worked out. Things are happening faster than the local tastes can absorb, and some commercial developments have the logic of an Internet land-rush, where presence equals success. The number of Kentucky Fried Chicken and Papa Ginos in Beijing probably have more to do with aggressive execution on the part of the companies behind these chains than a real taste for this kind of food.
Friday
Smog dominated the sky until Thursday evening. Thursday night was windy enough to blow the cap of smog off, and Friday dawned bright and clear. Bright sunlight, sharp shadows, and blue sky, as far different from the combination of smog and rain that greeted my arrival as can be.
The office where I was visiting now had a view of the mountains north of Beijing, a bit like the typical view of mountains in San Jose. The Imperial Palace and Tienanmen Square are as impressive as reputed, and very pleasant on a sunny day.
Sunday, May 13, 2007
What I learned at JavaOne, or: If I Were the Sun King
If you were at JavaOne last week, you would be reminded there is a another player on the world stage of computing: Sun Microsystems. They don't get noticed the way Google Apple and Microsoft do, and they don't have the aspect of a social movement that the Free Software Foundation, kernel.org, Mozilla, Eclipse, Ubuntu, Red Hat, and the other major open source projects and Linux distributions have. Sun is the last of the vertically integrated computer technology companies. This fact alone makes Sun's impact on computing potentially enormous. And the fact that Sun is widely ignored either means that Sun's ability to bind its technologies together into a strategic advantage has been poor, or that vertical integration, and a companies like Sun, are passe.
Sun has a new CEO, Jonathan Schwartz, and he has executed a tactical turnaround by focusing Sun on high-value customers. Sun is now profitable, for the first time in a long time, and that is cause for some optimism. But that optimism has to be tempered by a objective look at the size of the task ahead, and it the difficulty of each component of that task.
Another good reason to take a look at Sun's position in the industry is that there are some signs of strategic execution at Sun: Sun recently acquired the assets of SavaJe, a failed mobile handset software venture that left a 120 million dollar crater in a couple VC funds.
At JavaOne, Sun made several announcement that show the intention to move in the right direction, but this isn't they story of a sure thing. As of now, Sun has 20% of the market value of Apple, 60% of the revenue, and twice the number of employees. Sun has been so down for so long that making things right won't be simple, nor is there room for any lack of decisiveness.
In this blog entry, I take a look at each aspect of Sun's business as it relates to the industry and to major trends like open source, and see what Sun can do to improve their position, and weigh that against the costs. One thing that is clear from the outset is that Sun is engaged the computing industry at so many points it is hard to see them sustaining all of them without very strong justification for each. That makes the SavaJe asset acquisition all the more interesting: at a time when Sun must focus and decide what not to do, they have added mobile platforms to their agenda. Is this a brilliant move or a distraction?
Operating Systems
Solaris is characteristic of Sun's missed opportunities. Sun had the position of providing the best-supported UNIX-like operating system and squandered it through a complex combination of ambivalence regarding open source software, internal conservatism that prevented making radical changes in pricing, and lack of foresight regarding Sun's ability to compete without finding a parter (in this case, either Apple or open source distributions).
While anyone is free to download and use Solaris on x86 architectures, this gesture alone did not make Solaris a viable open source operating system. It didn't amount to more than a try-before-you-buy offer, and Sun's weak financial position through many consecutive quarters of losses made Sun's commitment to desktop operating systems questionable. While Solaris is in many ways still the best UNIX-like operating system, it must either be brought into a leading position in the open source operating system world, or Sun must use the open source community as a way of gracefully exiting the operating system business.
In either case, Sun must turn Solaris into a branch of the open source operating system and distribution taxonomy. That is, the Solaris kernel must become an alternative to the Linux kernel, much the way the BSD kernel is, and the GNU Hurd would like to be. And the Solaris userland must merge with the open source userlands and applications in the open source distribution world.
Solaris becomes, then, a collection of open source projects that feed into distributions, and, if Sun remains in the operating system business, an open source distribution that happens to emphasize Solaris projects. In concrete terms, merging Solaris with the Debian repositories wold be one way to implement this concept. Solaris as a product would then become a downstream distribution like Ubuntu, which would not be the worst thing to flatter with imitation, both in implementation and in business model.
A further irony is that Sun is executing well in some isolated cases, like NetBeans, but overall has failed to accrue the benefits Canonical (Ubuntu) and RedHat base their whole businesses upon. How long has Sun known internally how to get this right? Since 1993: http://www.redhat.com/support/wpapers/community/freeunix/freeos.pdf This is typical of Sun: full of individuals who know what to do way ahead of the competition, and no ability to act on what they know.
Languages
Microsoft has C# and the rest of the .NET family of managed languages. Apple has Objective C and Cocoa. Sun has Java. Java is the dominant managed language system for Web applications, which is arguably the dominant position overall among programming languages.
Java suffers from not being a revenue-generating product in proportion to the effort Sun puts into Java. But this is through no fault in Java. Development tools and languages are a thankless task. So the main benefit to be had is indirect.
Sun has lagged far behind Microsoft in making Java a usable client user interface language system, and has lagged integrating an IDE into the language system strategy. Only within the last year or two have these aspects of the Java language system strategy reached parity with Microsoft's .NET and Visual Studio products' capabilities. This lag is mostly the product of Sun's unwillingness to match the resources Microsoft applies to languages and tools.
Going forward, Sun must decide to either compete with Microsoft on a continuing basis, and not allow aspects of Java to fall behind, or Sun should find a way to exit the competition and turn Java and related products over to the open source community. Sun must also integrate Java with other product strategies. Currently, Java is not key to the Solaris userland. The open sourcing and dual licensing of Java finally made it acceptable for inclusion in mainstream Linux distributions, but Java has not taken its rightful place as the .NET equivalent in the Linux world. Sun is moving in roughly the right direction with Java, but has a very long distance to go:
Sun's Java should be more thoroughly blended with the open source world. This means a more cooperative stance w.r.t. alternative implementations.
The Java Community Process, a name containing at least four separate untruths, should be scrapped in favor of a process modeled after Internet RFCs.
Java should be made scalable on the client, and the Java CDC variant should be scrapped in favor of a scaled-down Java SE. There should be at most three Java variants: a minimalist Java ME, Java SE for almost every desktop and device, and Java EE for servers – but the client and server Java line might blur to the point where that distinction no longer works.
Java should be multi-platform (multi-CPU, that is) out of the box.
If Sun does not speed up the integration of Java with the open source movement, Java will lose to simpler open source dynamic language alternatives, and Microsoft will make further inroads into mobile devices with their relatively coherent implementation of .NET across desktop and mobile devices.
Hardware
While Sun can continue to compete in server hardware by building the biggest server systems, Apple has set the tone for how to compete in desktop hardware: Adopt the best CPU over the long-haul, and differentiate using software and design.
Sun has all the ingredients to be a world-class competitor, but has flubbed the execution needed to stay in the desktop computing game. Most of the rest of the UNIX workstation business died so long ago it forms a fossil bed under San Jose. There may be a business in super-high-end visualization workstations, but for 98% of users, PC hardware is a commodity and is best left to the master commoditizers. Sun should sell their workstation business to someone who wants to become a high-end desktop OEM.
CPUs
Sun cannot justify being a CPU company without having a long-term sustainable advantage. Sun cannot afford the capital to acquire that advantage, nor the price of failure: Could Sun take a hit like AMD just did? Sun should therefore exit the CPU business and focus on, for example, chipsets, clustering hardware, and storage systems to sustain Sun's position in high-end server systems.
Applications
On top of operating systems, languages, hardware, and CPUs, Sun is also an applications company, with the Star Office/Open Office products. Like other aspects of Sun's portfolio, Star Office/Open Office is a mix of grassroots open source success and standards leadership, combined with under-resourced development and lackluster product management, resulting in a lack of truly distinctive features in a rigorous competitive environment. In other words, Sun is lucky to have an opportunity here, but should not mistake that luck for an excuse not to focus resources.Sun must, again, decide whether to keep this product, find a new home for it, or fully transition it to the open source community. For it to make sense to keep an office productivity suite, Sun must get on track to re-entering the desktop computing game as a software and/or hardware maker. Star Office/Open Office must move closer to Java as the glue between software subsystems.
Mobile platforms
It almost seems like piling on to say that Sun, at a time when it must make hard decisions about what to do, and what to get out of, has taken on another operating system, another Java variant, and has entered the mobile platform business when others, like Symbian and Palm, are illustrating what a difficult and thankless business it is.
Without extreme clarity of vision in identifying customer needs and quickly shaping the former SavaJe mobile platform assets into a winning product. Sun will have dissipated resources in reaching for the seductive unit volume of mobile handsets when it just can't afford such dissipation.
SavaJe left a $120M crater in the surface of planet VC part due to building their own operating system in a market where embedded Linux is super-hot and entrenched proprietary platforms are mature and reliable. Even mighty Apple is having trouble birthing a new mobile OS. Does Sun have the focus to question this aspect of the value of what they just bought? Can they mold the already unfocused SavaJe user interface into something that addresses concrete needs? This acquisition is an albeit inexpensive daredevil move by a company that should probably keep the skateboard in the closet. It could be made to work, but without strong signs of excellent execution in other areas, or, alternatively, a excising of marginal products in order to put overwhelming resources on mobile products, this is likely to end up as another under-resourced dispersion of focus. Moreover, the mobile software world has only the faintest glimmer of an open source ecology. Sun can't offload part of this burden they way it has with OpenOffice. If it fails it fails hard.
What if they don't?
What if Sun does not move to get on the right track in each of the expansive range of product categories in which it now participates? If Sun does not focus Sun, Sun will likely be focused through external actions. Private equity companies roam the landscape, scarfing up slow, fatty dinosaurs. Sun could become the target of such a takeover, with the tarnished crown jewels being sold off to defray the cost of buying Sun, which would then continue as a server OEM and services company, unburdened of the responsibility for workstations, Java, Solaris, Star Office, SavaJe, and SPARC.
That might happen. But I hope the alternative prevails, and Sun re-emerges as a key player in the computing industry. The computing industry would benefit from another strong participant in all the important technology categories, and open source has provided a new opening for a competitor to enter (or re-enter) such a position in the industry. Sun has an amazing collection of people who are more than able to achieve any goal. Which is to say, it comes down to leadership.
It would be fun to download an Open Solaris with a unique eye-candy-rich Java-shell/desktop that installs as painlessly as Ubuntu, and that lets me mash up my Open Office documents with Internet applications using Java, and that integrates nicely with a viable mobile software platform. I also hope this visualization of a good result illustrates how large is the task. If Sun can't see themselves getting there, they ought to plan for what happens when they don't.
Posted by
Zigurd
at
11:15 PM
2
comments
Saturday, April 14, 2007
You Can't Spell DRM without "A-S-S"
The lesson is: Don't ASSume. Don't assume that DRM will be around forever. Don't assume that the computer and telecommunications industries won't throw off the yoke of DRM to achieve more growth. With one modest epistle – not the “tear down this wall” flourish you might expect from Steve Jobs – the future of DRM was thrown into question. Subsequently, EMI tore a hole in the RIAA members' hitherto seamless adherence to DRM, and Apple removed the barriers to using EMI music bought from iTunes on other music players.
Content protection of consumer media products has been around in one form or another since Hollywood got all itchy about consumer videotape machines and started fooling with the signal to prevent tapes from being copied. Macrovision, the most successful developer of tape content protection was founded in 1983, and is still around, protecting digital content from the people who buy it. Other early forms of content protection include market research reports printed on blue paper, with watermarks and serial numbers, to thwart photocopying.
DRM, the digital form of copy-protection, has been a topic of serious research for about the past 20 years. Video games, commercial computer software, data compilations, typefaces, clip art, etc. use, or have used, various forms of content protection to try to slow down use of commercial digitally stored products in ways that contravene the license agreements that sellers of these products use to create an environment in which – in general terms – content belongs to the provider and is rented to customers. DRM is the prevalent form of content protection today because copying digitally stored content is fast and cheap, and this has raised the stakes: Any “leak” of a digitally stored product can be quickly turned into thousands or millions of copies.
The moral and legal basis for contracts licensing the use of intellectual property long predates recorded performances as a consumer product. In the U.S., copyright and patents were created, in the words of the United States Constitution...
To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries.
That's it. Anything outside that authorization, in U.S. federal law, is illegitimate in that it has no constitutional basis.
There are three distinctive aspects of intellectual property: 1. It is a right created by government. The right to intellectual property is not an inalienable right – it is not one that exists with or without government acknowledgment. 2. It has a stated purpose. No other human right has to justify itself. 3. It expires: You own your property forever, but your copyright or patent expires and your “ownership” or, more correctly, your exclusivity in use, licensing, or publishing, is over, in order to create a greater common holding of knowledge and art.
So how did we get from such a weak, limited, qualified, and overall second tier right as that created by this cautiously crafted clause to today's ponderous, invasive, unbounded, intrusive, over-lawyered, kudzu-like thicket of laws and technologies? Consider, for example, showing the “FBI warning” on a DVD recording, that says you will become a felon by doing something untoward with a DVD of Howard the Duck, to one of the people who drafted the Constitution's intellectual property clause. Ask them “Is this what you meant?” Never mind the DMCA and other sausages of dubious legal content.
The 100 year history of recorded performances has funded a tsunami of lawyers and lobbyists that have succeeded in overwhelming all restraints on turning our intellectual property laws into a travesty of original intent. Starting on the basis of such raucous cognitive dissonance, no wonder the modern pursuit of intellectual property has overshot even the most elastic bounds, and is now starting to snap back.
Steve Jobs's objection is, like any reasonable view of intellectual property, both pro-freedom and pro-commerce. DRM has failed the business of selling music recordings. Two or three out of a thousand songs on iPods are sold from Apple's relatively successful Internet music shop. The rest of the DRM-protected music download business is a miserable failure, just like DRM-protected e-books were a readily predictable irretrievable flop, and for much the same reason: Even the most apathetic consumer sees the value of the ability to transfer, backup, and migrate their music collection. DRM thwarts these basic requirements. The value of buying and selling in a secondary market is also completely extinguished by DRM.
The response of the recorded music industry was to try to eradicate any choice other than DRM'ed music. As if making a content gulag that was so big you could not see the barbed wire perimeter would make it seem like your content was not imprisoned.
Content protection does not always fail. When is the last time you heard someone complain that their Nintendo DS uses content protection? You don't hear such complaints because all the software runs on all and only that hardware. You can buy a DS cartridge, transfer it to another DS, sell it, and buy a different used cartridge exactly as if you were buying and selling books. The product is tangible and your use of it is in practical terms irrevocable. You don't use a DS for private documents. You can chat on it, but it isn't a general-purpose communications device, so there are no privacy concerns. DRM, when it is un-intrusive, and non-essential to any truly important personal matter, does not stand in the way of product success.
People who make DRM systems have no excuse: The examples that work are out there. Failure to realize that anything outside such closed ecosystems is damaged by DRM to the point where customers reject it as defective is entirely the fault of the system designers.
How far will this backlash lash? There is another change in Apple's position on DRM that is also noteworthy: In October 2006, Apple stopped using a Trusted Platform Module (TPM) on its motherboards. Trusted Computing is a delightfully newspeak term. It means you, the computer owner, cannot be trusted, and that certain data and code has to be hidden from you on your own computer. Trusted computing is, of course, antithetical to Personal Computing. If you don't control every bit inside your computer it isn't personal. In fact, it is partially owned and controlled by someone else.
The full exposition on Trusted Computing is a topic for another post. But the summary of the problem is that computers are an all or nothing affair: Once you let that tiny bit of camel's nose under the tent, you will have a tent full of camels in short order, each of them snooping on behalf of some interested party, be it the people who think you might be a terrorist, or the people who think you have evil intent for their music recordings. One could even implement some form of “Information Purification Directives.”
If Apple smells an opportunity in reasserting the Personal part of Personal Computing, especially as Microsoft appears to be turning your PC into a servant of the content publishers, we may see a very interesting phase of the PC business emerge.
Posted by
Zigurd
at
2:38 PM
2
comments
Thursday, February 08, 2007
The Meaning of iPhone, Part II
.
This is where it get provocative:
- iPhone uses the mobile network as a backstop. The real action will happen on iChat, over WiFi. The iPhone platform is sure to be used in iPods that don't have a mobile phone radio in them. But those iPods will have WiFi, and they will be communications devices as well as media players. Communication will be an Apple product, but not the way the mobile network operators would prefer. iPhone is turning mobile service into the dial-up modem of the 21st century. The mobile carriers have been quarantined into providing switched circuit voice service in the iPhone, and left out of iPhone's commerce and higher-value communications.
- iPhone is an embarrassment to 3G. iPhone isn't selling music over 3G. Unless there is some unforeseen disaster in iTunes sales because people can't buy music while driving, iPhone will show up 3G data service as not having found an application. The premier mobile media commerce channel brushes off 3G as unnecessary in a mobile product, and the network operator accedes to this decision. Verizon turned down iPhone, and Cingular snagged a long term of exclusivity, so it's also a missed opportunity for EVDO and MediaFLO.
- J2ME is a ghetto for low-rent games. Too limited. Too security obsessed. Too much rigmarole to install and manage applications. Too fragmented to support applications that have a lifecycle. What could have been done in J2ME will be done in widgets or Cocoa (or in Symbian-native apps on Nokia handsets, or in .NET Compact Framework on Windows Mobile devices). However, most mobile applications will be AJAX running in full-featured embedded browsers. Java on devices? Make it Java SE on Linux, which is a fine alternative to .NET and Cocoa, is needed for applet support (dirty little secret: some of the best “AJAX” is actually applets), or fuggedaboudit.
The communications part of mobile telephony can be made more valuable and more powerful:
- Presence is the killer feature of IMS. Presence that is standardized and that interoperates across service providers.
- The user interface should have presence at the center, not off in a cheesy push-to-talk application written by a 3rd party and with a UI that looks like a programmer drew it with a crayon.
- Presence is common to mobile and Internet communication. Make something out of that fact that makes users go “oooooooh!”
- Real-time and messaging are a continuum. Push-to-talk is the bridge.
- All messaging is the same – to the user. Break down the protocol-based silos.
- Find applications and lead experiences outside of mobile media: Enterprise integration, social networks, etc. Don't bang your head against iTunes.
The mission for the mobile industry is to add value to communication. That's easy and natural in IP media, and anyone can create a new application. If comparable natural flows among modes of communication are available on mobile devices, users will go with mobile networks for their pervasive coverage. Blending the mobile network's pervasive availability with Internet applications captures the best of both worlds.
IMS both creates opportunities but it presents a potential blind alley, too: IMS makes mobile presence-based applications, like PoC and instant messaging interoperable and standardized, but it also plays the siren song of “service creation” - a blizzard of new services that won't add much value and that will confuse users. Stay away from things that duplicate a Web service using IMS.
Posted by
Zigurd
at
11:05 AM
0
comments
Thursday, February 01, 2007
Calling All Telecom Bloggers
.
Have you got something original to say about the ways that humans communicate over a distance? Comment this post and let us know about your blog.
Posted by
Zigurd
at
1:31 PM
4
comments
Monday, January 29, 2007
The Meaning of iPhone, Part I
iPhone was announced, raised up as a messianic product, suffered a backlash (already, five months before it ships), and is still supplying fresh blogfodder:
First, what everyone knew from 10 seconds into the demo, is that iPhone is not a defensive move. Apple did not merely forestall what has been the oft-repeated and never realized prediction that mobile phone unit volume would inevitably crush iPod under a tide of carrier-subsidized music players. Apple is now the maker of the most desired phone on the planet.
Nobody has ever gone from zero to the very top of the game with their first mobile phone product. Expectations for the iPhone were that it would be a Very Nice Phone inside of an iPod. But only that. Instead Apple has created a new mobile phone OS and UI platform and implemented it to a level of polish above all others. They put this new software into a vessel that is, once again, the nicest package in the business. Only this time in a demanding and mature business to which Apple is a new entrant.
How much better is iPhone? Despite the very competent efforts put into mobile user interface systems like UIQ and Series 60 UI, has anyone ever really been impressed by the results? At best, users of existing products find them adequate. Inoffensive. Nice that they don't often get in the way of an important task, like reading e-mail. Meeting this standard is what Apple was expected to do. Instead they passed it from a standing start and are now in the lead.
The only knock on the iPhone is that it does nothing new, other than provide a visual interface to voicemail. But even that modest advance was a zinger. Handset product managers world-wide are dope-slapping themselves for not pushing that through in the fifteen years since that has been technologically do-able.
But this is Apple: Making the object of desire is just the start. Apple also took the challenging environment for selling a mobile phone into the U.S. Mobile network operators' channel and turned it into a work of art comparable to the iTunes contract negotiations.
By giving a willing network operator the temporary advantage of exclusivity, Apple got at least two critical benefits: Apple set terms that drive a wedge into the garden wall of mobile content sales by keeping iTunes sales off the mobile network. Apple also got the benefit of not having the iPhone subsidized by the network operator. That's correct – the benefit. In both cases one imagines the negotiations to have gone a bit like asking not to be thrown into the brier patch.
By keeping iTunes sales off the mobile network Apple completely hornswoggled Cingular. Cingular is a network operator. So who came off worse: Apple, for having to require that their customers use WiFi to download iTunes purchases? Or Cingular for having failed to sell the use of their network for this purpose? Cingular has ripped a hole in the wall in order to get that big wooden horse inside. Users of Nokia E-series handsets already know the real Web over WiFi is a much nicer experience than the mobile Web. Now millions of Cingular users will be comparing the iTunes over WiFi experience with the typical mobile content shop experience.
Which leads to the next issue: Why would Cingular subsidize an iPod, especially when it isn't using Cingular's network? Turns out they don't have to. Which also frees Apple from the prospect of music-only iPods competing against subsidized iPhones, and from mobile network operators using varying levels of subsidy, resulting in a range of iPhone prices, once the term of exclusivity expires. No subsidy also makes it easier for Apple to sell iPhone in Apple stores.
Keep in mind that MNOs' executives had not seen the iPhone. The only precedent they had to work with was the first iPod, which was hardly a revolutionary looking device. In agreeing to terms that appeared to be solutions to some practical problems when they were negotiated, they gave Apple the levers to move the mobile handset business in directions advantageous to Apple. As in the case of Blackberry subscription revenue, the mobile industry is willing to shift on some fundamental points of the handset vendor relationship if the handset brings with it significant end-user demand. But unlike Blackberry, it wasn't just a matter of revenue sharing.
It took two years for iPod to gain momentum. Analysts project that iPhone will take 1% of the mobile phone market fairly quickly. If sales fall into the range of 5 to 15 million units over 12 months Apple will roughly match their only near-direct competitor: Nokia Nseries, which sold 6 million units last quarter. In about two years Apple will have a product line as broad as Nseries, and could take 5% of the mobile handset business, and a really hefty chunk of the total profits, since Apple won't be selling any low-end handsets.
Are Cingular chumps for agreeing to these terms? Not really. They will look like geniuses for seizing what will be one of the very few opportunities to move a couple million subscribers to their network. The strategic impact of iPhone on the mobile industry will only be felt once the product exists in millions of units, and it will be spread throughout the industry. Apple will be free to set pricing of handsets, and will be free to operate a parallel commerce channel on a parallel network. No other handset maker has ever taken as much away from a negotiation. Even Qualcomm would be jealous of that kind of leverage.
What about the impetus – defending against mobile phones that are also media player? It sure looks like iPhone is a solid defense. But is there really a threat to defend against? Apple will sell more than 100M iPods in 2007. That is about one tenth the number of mobile phones that will be sold. The iPod market is now too big to be “crushed.”
Those engaged in building a mobile phone-based music business will have to contend with a fragmented handset technology and m-commerce landscape. Only Qualcomm and, perhaps, Nokia have control over enough of that landscape to mount a challenge, and to do it comprehensively from e-commerce channel to handset. On top of that, a mobile music challenger will have to use the mobile data network to deliver content of similar quality to that available on iTunes. And on top of that the prices will have to meet iTunes prices. Being able to buy on the go, out of WiFi range, just isn't enough to justify a higher price.
By the time a mobile music challenger really gets going, Apple will have new iPhone models on the market, and will be on the way to taking 5% of the mobile handset business and not just defending itself against the mobile music business, but being the mobile music business.
Posted by
Zigurd
at
7:49 PM
2
comments
Labels: iPhone iTunes mobile Cingular Jobs negotiation iPod m-commerce
Wednesday, January 03, 2007
A Brittle Monopoly, a Fragile Revolution
Vista will have a broad-based launch soon. Unlike the launch of Windows XP and Windows 95, buyers won't be lining up outside stores to get the first copies. Vista is late, and Vista benefits are uncertain. This uncertainty was not helped by Microsoft's longstanding and widely publicized fascination with DRM – the benefits of which were seen by customers as ranging between dubious and toxic.
The other recent Microsoft product launch – the Zune – did not add to Microsoft's momentum. Zune is a geeky, awkward device that adds DRM to your own rips. It is promoted by an ad campaign with an obscure and awkward strap line that feels like something out of a “your brain on drugs” ad. And then there is the “squirting.” Oh, the squirting.
With all the bad news about Microsoft, you might be shocked to find statistics that say that 90% of the installed base of PCs are running various versions of Windows.
One can argue that the number is flawed. But the numbers that all add up to around 90% come from various sources, with diverse methodologies, such as retail sales and Web-site visitors. So 90% can't be attacked as a static measure, or one that is skewed by showing only one kind of computer user.
Another measure that suggests a near-monoculture of Windows is that viruses and spyware are almost exclusively targeted at Windows. Or, look at a catalog: Even the catalog of a “hobbyist-friendly” outfit like Micro Center has, maybe, 3% of desktop PCs with Linux. The rest run Windows. 0% of laptops come with Linux installed.
All indications are that personal computing still at the very narrow end of the wedge of restoring diversity in end-user operating systems. This is a movement that could be crushed or turned back. It certainly has not become strong enough that it is certain to survive.
However, when change comes, it will be sudden. Either Linux will be banned as too subversive for society, law enforcement, and content publishers to tolerate outside of Web servers and embedded applications, or Windows will precipitously fall from its position of near monopoly in the installed base of client operating systems, driven into retreat by the polish of Apple's MacOS and the freedom and democracy of open source.
The reason that change will be abrupt is that the Windows monopoly is brittle. It is brittle because it is based on hegemony in licensing to manufacturers, and on taking the content publishers' side in promoting DRM even as publishers become more strident, restrictive, rent-seeking, and litigious in their view of how content can be used by consumers.
This isn't the road to general popularity, much less is it the way to keep opinion leaders on your side. Any customer that is smart enough to be aware that their computer is going to rat them out to content publishers (and who knows who else) resents it. While most consumers are unaware or apathetic, opinion leaders are almost uniformly against DRM. Microsoft failed to grasp early opportunities to show DRM could be used to secure users' documents against misuse. That might have shifted the argument to something closer to a balance, but as it is, DRM is purely a source of resentment, without identifiable benefits.
Microsoft also appears to have a tin ear for the resentment against DRM. Apple is praised for pushing DRM mostly out of sight, while Microsoft is in the news for completely embracing DRM to the extent it is fundamentally changing the nature of a personal computer from a machine the user controls completely to one that is outfitted for surveillance and control by publishers (and who knows who else).
But all that does not mean that the Forces of Good will triumph. It does mean that the conflict over free and open software will be sharp and full of rhetoric about how free and open software is the tool of drug kingpins, terrorists, and pornographers. This rhetoric, and laws that make general purpose computing and communication tools contraband, will be used against free and open software. It will be used to hang the threat of liability over computer makers in order to maintain license hegemony.
Is Microsoft's share price stagnation and Microsoft's position for DRM linked? Before answering that, let's also ask if there was a different corporate culture at Microsoft when it was in ascendancy.
Microsoft's success was based on providing an inexpensive, off-the-shelf computing system that was good enough to replace many expensive minicomputer and mainframe systems that held customers hostage to high maintenance fees charged by hardware and software vendors. For those who could not afford minicomputers, Microsoft's software used to be the tool the little guy could use to level the playing field.
When Microsoft was on the way up, they were breaking eggs and making omelets. They were making other companies' products obsolete, and delivering high value, and driving companies like Wang, Digital, and Data General out of business. Now they are in the business of preventing the RIAA and MPAA dinosaurs from shuffling off to the tar pits, preventing corporate computer users from doing anything their IT department does not approve of, and preventing you from knowing everything going on inside your computer. That is, Microsoft has gone from selling creative destruction, to preserving obsolete business models, corporate IT controls, and facilitating content publishers' and others' intrusions into your use of information.
Does this mean Microsoft is doomed? No. Microsoft has thriving businesses in appliance devices like mobile handset software and game consoles where customers do not expect – yet, anyway – to have full control over the device. Microsoft's Office Communications Server is a dagger at the heart of the PBX business, and very much fits the model of the ascendant Microsoft. These parts of Microsoft will grow rapidly in the coming years.
It does mean Microsoft is in a vulnerable position on the consumer desktop. Like GM that can't compete with BMW quality or Hyundai price, Microsoft Windows is becoming a product only for those that don't care about having something better: Apple will be the choice of customers that can afford Apple, and Linux will be choice of those that value a true personal computing experience. Microsoft will be left with the sort of people who still buy Buicks. On top of that, depending on the extent to which DRM becomes visible to end-users of Vista, Windows will also become a product for people who don't care about not having Big Brother Inside. That may sound like an extreme comparison, but there was just recently a time when it seemed like GM could go on selling Buicks forever, too.
To really turn itself around and gain a path to new growth, Microsoft has to say no to the content publishers and say yes to end-users' concerns about privacy and control over computers and content they buy. But I don't expect Microsoft to do that until the message is written in declining market share and further stagnation of the company's value.
Posted by
Zigurd
at
11:17 AM
0
comments
Monday, April 24, 2006
Writely or Wrongly, WebOS is Coming
Predating the first Internet bubble, there was the applet craze: It was thought that software would be delivered through the Web, on demand. Java was riding high on this fad, and lost a lot of credibility when the immaturity of Java technology (i.e. the unsuitability of AWT for making big, rich UIs on PC clients), low Internet connection speeds, high bandwidth costs, and Microsoft’s adverse reaction to hosting a potentially undermining technology in the bosom of their desktop OS, worked together to make applets less of the big deal than the pundits made them out to be.
Microsoft was able to contribute to blocking this disruption, but was not able to directly counter it or provide an alternative. .NET, like Java, became one of those dull gray tools of the IT crowd – a means of making multi-tier software systems without the hassle of understanding the complex threading implementations needed to make a middle tier that can serve thousands of users. This, despite the fact that .NET implemented code-behind-HTML and other features that made it quite a good tool for delivering user interface in Web pages.
Web hackers – the sort that don’t program in Real Languages like C# and Java - who never got the memo about server software, kept plugging away at making the Web user experience better.
“Better” means escaping the UI-as-form-filling paradigm that gave the Web a plodding, oppressive feel any time user input was required. The Web was born a hypertext system. Accommodating interaction beyond that required for hypertext is something that should be unsurprising in its difficulty.
Mapping MVC architecture onto multi-tier Web applications is not easy. In Web applications, the model is usually a relational database. The view is projected by middle-tier through a Web browser, which may include client-side code in Javascript. This complexity, and the hypertext heritage of the Web browser keep sucking Web UI back to a series of forms to fill out.
A rich Web user interface has to be debugged across multiple tiers, and, in the case of Javascript, across the client-to-middle-tier network connection. So, most Web UIs fail to grasp how to bring a consistent and highly interactive experience to the user and settle for the equivalent of what passed for UI back in the days of DOS, but with a prettier layout.
For an idea of the size of this problem and the value of simplifying the solution, take a look, on the one hand, at Enterprise Java Beans, even in its much cleaner 3.0 implementation, and, on the other hand, Ruby on Rails, which epitomizes the Web 2.0 ethos of productivity over universality. By focusing on solving exactly the above specific problem, which, while narrow in scope, vexes a large number of application developers, Ruby on Rails struck a very resonant tone, and has made an impression beyond the number of projects that actually use Ruby on Rails.
Ruby on Rails belongs in a spectrum of technologies we can call “Web OS.” Web OS is a system for running and building applications that run on Web servers and are used through the medium of a Web browser. Ruby on Rails is at the “building” end of the spectrum, while application suites like Writely, Gmail and Google Calendar, that have Web services interfaces but no SDK, are at the “running-only” end of the spectrum (although you can be sure Google has an impressive set of tools for their own coders).
We will soon see a lot more Web OS attempts, and, hopefully, some successes. Success, in this context, means making it possible for a large number of coders – not just those with Google's resources for toolsmithing – to create and run rich Web-based applications that truly break free from the “screen A -> screen B -> screen C” model of UI misdesign.
Whatever you may think about having your documents live on a server and editing them with tools that also live on servers, the WebOS future is likely to provide some interesting results: One easy prediction to make is that the mash-up culture will spread to all manner of applications, whereas the component document technologies that were supposed to put a spreadsheet inside your word processing document never really delivered. Maps, communication, auctions, translation, etc. will drop into Web OS documents naturally, because the data and communication that animates these document mash-ups will be available and compatible.
This is what makes Web OS interesting. If it stopped at implementing MVC applications in a particularly challenging implementation environment it would be only a technology curiosity, and probably not enough to motivate investment. But Web OS applications really can be better.
It's a good thing developers of these applications were never told how hard that is to do.
Posted by
Zigurd
at
2:30 PM
0
comments
Thursday, February 02, 2006
The Model-View-Controller Design Pattern and iPod-like User Interfaces
In my previous blog entry I asked whether the iPod is an example of a new user interface paradigm, and concluded that it is. This time, I try to provide more of the nomenclature for describing user interfaces of this type.
Discussion of desktop user interfaces is much aided by the desktop metaphor conceptual framework, augmented by the MVC (model-view-controller) design pattern. The desktop metaphor describes how overlapping graphics contexts give rise to on-screen windows that mimic the look of overlapping pieces of paper. MVC provides a design framework for (potentially) multiple views of the same data to be present on the screen and to stay in synch as the underlying data changes.
Together, the desktop metaphor and MVC are the foundation of nearly every non-trivial desktop user interface. iPod-like user interfaces discard the desktop metaphor. Overlapping objects are out of place on the iPod. They have no metaphoric meaning, and the screen is too small to give overlapping objects enough visual context.
In the desktop metaphor, each window is a viewport into a two-dimensional document that extends, mostly, above and below the view the viewport provides. In an iPod-like user interface, the whole of the screen is a viewport into a document consisting of a network of nodes. And here is found an interesting connection to the desktop metaphor: Most document data models are networks of nodes: Web browsers’ data models of Web pages, for example. The iPod, therefore, achieves an elegant presentation of a document by being one step closer to the type of data model used to model many documents.
The iPod shows that MVC is not inextricably linked to the desktop metaphor: The iPod has a model, a view, and a controller, although each is simplified: The model doesn’t change until iTunes changes it, the view is a full-screen view of just one set of nodes which all are children of the same parent-node, and the controller provides no means of editing the content of nodes.
Not every element of the desktop metaphor is a success. The desktop metaphor is plagued by an innovation known as the dialog box. The dialog box is familiar to most users, and in its most florid examples brings no less joy than a long session of filling out tax forms. The dialog box was a feature, used sparingly, in early desktop metaphor user interfaces, to put a pressing matter in front of the user, in situations where the user could not proceed without at least acknowledging the matter, e.g. a serious error. Since then, user interfaces have experienced a metastasis of the dialog box as mediocre designers, armed with visual dialog box layout tools, have attached numerous multi-tabbed tumors to software. Pre-AJAX Web user interfaces brought the dialog box to its pinnacle of dominance: If you have ever filled out a multi-page “registration” for some Web site, you know it well.
The iPod does without dialog boxes, not least because text entry on an iPod would be brutally hard, but also because dialog boxes, like other overlapping elements, have no good visual representation on an iPod-sized screen. The lesson embodied in the desktop metaphor’s encrustation of dialog boxes compared with the iPods lack of such goiters is that designing the direct manipulation of the data model is hard, and widgets, dialogs, and menus are easy. The iPod escapes this damage by being an environment that is hostile to the concept and implementation of dialog boxes. The iPod is also a browser, not an editor, and therefore manipulation means viewing, not modification.
Can this simplified MVC user interface survive being extended into providing a first party call control user interface? Or a mobile commerce interface that brings iTunes Music Store into a connected iPod? While these are not small design challenges, there is reason to think this simple and elegant UI paradigm can encompass new functions without losing its qualities: First party call control is not document manipulation. It has its own very severe challenges, but it should not require a fundamental shift away from the iPod user interface. Similarly, shopping can be thought of as a series of database queries followed by the user browsing the results. This, too, should be possible to implement in the iPod paradigm without warping it out of shape. These examples are not randomly chosen: If there is to be a wirelessly networked iPod that includes a PLMN or VOIP telephony subsystem, these are the major components that would have to be added to the iPod user interface.
The iPod can also be categorized as a “one-handed” UI. One-handedness is also linked to the lack of overlapping elements in the iPod UI: If you don’t have a pointing device to access overlapping elements the way you would access papers on a desk, you should not have them in the UI. Failure to heed this distinction between one-handed and two-handed UIs leads to such kludges as “two level focus” and other severe compromises that are inherently incomprehensible and inexplicable to users. For examples, you can look to any mobile handset HTML Web browser that attempts to map the two-handed PC Web browser human interface to a one-handed handset interface. Microsoft still struggles to fully reshape the two-handed Windows CE user interface – which is a fine user interface if you assume the user is holding a stylus – into a friendly one-handed UI for mobile phones. Two handed UIs allow rich and ambitious interfaces, while the iPod’s strict observance of what the user’s thumb is capable of leads to an entirely different result.
The iPod, therefore, can considered to be a full-fledged example of a distinct user interface conceptual framework. It has all the characteristics of the consistent application of such a conceptual framework to an implementation. Graph or network traversal, one-node-at-a-time views, mapping of architectural aspects to the MVC design pattern, and extensibility to other application domains put the iPod UI alongside the desktop metaphor as something that we will likely see more of, in other types of devices, applied to other domains.
Posted by
Zigurd
at
10:41 AM
0
comments
Tuesday, December 27, 2005
A Mobile User Interface Paradigm
The iPod interface is not original, and the USPTO has thus far ruled it isn’t novel. Creative Labs and Microsoft both hold related patents, and a hierarchical user interface is fundamentally unoriginal. But, as with Macintosh, taking a good idea more seriously than one’s competitors has given Apple the leading position in establishing the iPod user interface as the best example of a new paradigm.
That new paradigm can be summed up as “node by node visualization of taxonomy browsing.” Evidently I won’t go down in history as coining a new moniker as succinct as “desktop metaphor,” but the concept of taxonomy browsing on a small screen deserves almost as much exposition as the desktop metaphor in order to explore what it can do for small-device user interface.
On the iPod, the taxonomy is composed by iTunes and downloaded into the iPod. The iPod user browses the taxonomy node by node. That is, only one node of one taxonomy is viewable at any one time. That sounds rather unattractive, for a couple reasons: First, it comes off as limiting. Who would not want to see more information if they could? Second, “hierarchy” has become a bad word. Search-based file browsers on PCs are happily burying one of the worst user interface ideas ever created in computing – the file hierarchy.
And yet, the iPod is clearly a brilliant user interface. How does Apple turn limitations and what seems to be an out-of-style idea like hierarchy into user interface gold? With two broad approaches: First, accept limitations. Do not strain to deny them. Second, work to create the best user interface within the limitations. Much the same could be said about the difference between Lisa and Macintosh. Lisa did not accept limitations. Consequently, it was slow, and it highlighted the limitations of the Lisa platform. Macintosh accepted tighter hardware limitations than Lisa, and did what was needed to provide an excellent user experience within those limitations. Apple, in the person of Steve Jobs, and institutionally, clearly remembers those lessons.
In the iPod, limitations are ameliorated by the perfect interplay of the physical user interface and the “trail of crumbs” browsing interface. It enables the user to access one branch of a taxonomy so easily that the one-node-at-a-time limitation of the view into the taxonomy is no burden. In fact, compared to more-conventional taxonomy browsing interface of iTunes, it is a model of clarity.
Is this really a paradigm? Is it applicable to domains outside of music taxonomies? With specific examples thin on the ground one has to drill into the paradigm to come up with an answer. Here, I will state that answer in the form of how iPod-like taxonomy browsing fits the model-view-controller architecture for user interfaces: If the model is static, or nearly so, and if the model can be created from some interaction outside the hierarchical view system, such as the iTunes database, or some other database query, and if the results of that query form one or more taxonomies of categories, with nodes of manageable size, then taxonomy browsing iPod-style is a valid paradigm. Speculating on what kinds of applications fit this description, one can think of social networks, heterarchies like semantic networks (such as the CNet semantic network of news stories), and even first party call control interfaces, which I have seen implemented as a menu hierarchy attached to a tray icon.
I think this is enough to define a taxonomy browsing user interface paradigm, and test that node-by-node visualization and trail-of-crumbs forward/backward linking are a good visualization of that paradigm. I did not delve into physical UI and controller design, and it may be that the iPod wheel is key, but I will assert it is not, and that the mobile handset dpad is sufficient (perhaps this will emerge as a single-button versus multi-button mouse theosophical topic).
Now how about some iPod phone rumors!
Posted by
Zigurd
at
12:14 PM
0
comments
Saturday, December 03, 2005
Why Mobile Java Has Not Converged on Compatibility
Mobile games are flourishing. Mobile games are modified – ported – dozens of times in order to run on dozens of handsets. That’s no way to make enterprise software, and the mobile game industry can support this practice only because most mobile games have no life cycle – they are not maintained or updated once they are released for a specific handset. If every time an update was released for a product the porting process would start all over, such products would never be economical or manageable.
It isn’t for lack of effort: Current J2ME standards show considerable progress over the MIDP 1.0 API standards. MIDP 2.0 provides easy standardized access to multimedia capabilities, an elegant and consistent connectivity model that spans connection-based networking, HTTP, and store-and-forward connectivity, and a form-based user interface system that enables custom UI widgets within a framework that abstracts display and input method differences.
Still, the mobile application environment has nothing like the application compatibility provided by PCs.
There are two main reasons for this:
- The J2ME standards are correct without being right. They are lawyerly in their concision. They can be defended as providing all the necessary definition – the contract the implementers must fulfill – and, yet, demonstrably they do not deliver a consistent target environment in practice.
- There is no body of applications to help identify slovenly interpretations of the MIDP 2.0 spec. The makers of compatible PCs had to show practical compatibility. The makers of J2ME implementations only have to smuggle their cruddy TextField and CustomItem implementations past a validation suite that cares nothing about the quality of presentation to the user.
Perversely, the lack of a practical compatibility test prevents the growth of a corpus of applications that would form that test. IBM’s PC attracted hundreds of applications that were being expanded and updated with an expectation of compatibility across IBM’s PC product line and new models before the first compatible clone appeared. These applications formed the basis of a practical test for compatibility. Mobile application compatibility has neither chicken nor egg.
Mobile search is one of the first areas where a mass-market application has to overcome the compatibility limitations of J2ME. Mobile search client applications will have a lifecycle. They will be updated. They will be released into a environment where it will be impossible to exhaustively test on every new handset. In short, they have to make the leap from the J2ME environment that is barely tenable for games, all the way to making it work for a mass-market product.
This won’t be easy, and many mobile search developers have concluded that J2ME is not ready to support such an ambitious application. They have stayed with presenting a user interface through the WAP browser, or they have started with smartphone platforms like Symbian and Windows Mobile as a basis for mobile search applications.
One problem with the latter approach is that Symbian and Windows Mobile phones constitute a narrow sliver of the market. There is also no great support among network operators and manufacturers to push smartphones. There is no distribution channel for large smartphone applications that must be installed from a memory card. Customers don’t know what benefit smartphones bring, and all the popular features like cameras, video, and mp3 music are available on inexpensive phones that do not tout themselves as “smart.”
The opportunity is in the billion or so Java-enabled phones that will be in the installed base by 2008 – within the next two or three product cycles for application development. If any mainstream phone will be “smart” by current standards, it will be mainly due to the price of hardware declining to the point where, for example, Nokia Series 60 phones become cheap enough they can come free of charge with a postpaid contract of a year or two.
So, can you just hang back and wait for the mobile application situation to fix itself? Only if it is satisfactory to see a billion people running around for several years not using your software. With numbers as big as they are, you have to try. So, what can you do?
You can:
- Use the available tools. As imperfect as the MIDP 2.0 UI tools are, they are better than rolling your own, which cuts you off from platform-specific input methods, like voice input, that are accessible only through the built-in UI widgets. MIDP 2.0 forms enable custom UI widgets with convenient interfaces to keypad and stylus inputs, focus management, and repaint management. Add custom widgets to your application to create powerful and distinctive user interfaces within the MIDP UI framework.
- Build tools where appropriate: While CLDC and MIDP 2.0 handle UI adequately well, and networking and multimedia quite well, they fail to address many practical issues in creating serious applications. Script-driven testing, logging, and update management are areas where you are on your own. Take the time to design these capabilities in harmony with the basic capabilities of J2ME.
- Write once, test everywhere, fix portability issues as if they are bugs – which they are. Don’t “port.” Compatibility is within reach, although it may not seem that way when first you begin to test an application across multiple KVMs. The numerous issues you will discover will make you want to give up the pursuit of compatibility and adopt the game publishers’ approach of creating a “port” for every handset. If you persevere past your first handful of handsets, compatibility on subsequent platforms will come easy, and by the time you are done with testing on 15-20 handsets, you will have achieved compatibility on dozens of handsets.
- Test everywhere, and use the update tools you built to keep your handset compatibility footprint growing. You will perpetually find new issues. But if you successfully fit the solutions to these issues into a single widely compatible build, you will have the ability to update your applications quickly and with minimal pain. This is the payoff: When you achieve wide compatibility, your next major application rev will ship with accessibility to the most customers, with the least support burden, and it will ship more quickly than your competitors’ applications. If you succumb to the port-per-handset approach, your rev 2 launch will suffocate under the load of porting, testing, and release management.
There is a reward for the first developers to cross the compatibility threshold in mobile Java applications. First-mover advantage in complex mobile Java applications is available, but hidden behind layers of challenges. If it was easy, everyone would be doing it.
Posted by
Zigurd
at
9:46 PM
1 comments
Sunday, September 25, 2005
Why Everyone Won’t Succeed
There are general answers: there isn’t room in the market for all the ventures that enter it to succeed; some will be undercapitalized, some will fail due to project risk. But those are unsatisfyingly unspecific answers. To provide a really good answer to why most attempts at mobile search will fail, the answer must, at least, carve out a slice of the problem space, and it must say how this kind of answer applies to mobile search, and how it does not apply to startups in general, or search in general. I find that there is a fairly clear and informative answer to why some people – and I aim to make sure this means “other people” will fail:
Unified messaging, the focus of a company I started many years ago, was also a case where mastery of two very different disciplines was required. Then, as now, however, the difficulty of integrating across two disciplines where you will seldom find experts in both is hard to measure, and is often not taken into account in measuring the ability of a venture to capture and defend a position in the market. That is, this is both a hidden danger and an underappreciated quality.
It is, of course, easy to enumerate the features of voice mail, and of email, but, as evidenced by the implementations, most attempts failed to integrate the two correctly. Successful implementation of the idea of unified messaging required insight into the direction – not just the current position – of voice processing and messaging systems, mainly in the area of emerging APIs and standard interfaces, and it required integrating this knowledge right through to the business model and business development strategies. Even Active Voice, which is widely regarded as the exemplary case in unified messaging for having the best integration to messaging standards, did not until fairly recently, when media gateway nodes displaced voice processing cards as the interface point, fully abstract hardware from the unified messaging system.
In hindsight is it fairly clear: unless you see where messaging and voice processing are going, you can’t position yourself correctly among your technology providers and channels. There is no obvious choke-point here – no way to deny a competitor who has figured this out access to the same partners and channels, so this isn’t widely seen as a differentiator. But the fact that so few entrants to the unified messaging field got this right means that interdisciplinary integration probably is a significant advantage that some ventures will wield with strong effect against their competitors. Not all ventures share this attribute, so there is probably something to be learned about building a venture where interdisciplinary integration is a requirement for success.
Mobile search is, if anything, a more difficult problem than unified messaging. At least three major distinctive areas of competency have to be integrated into a successful system:
By “compatible minds” I mean people that can flex to fit the requirements of interdisciplinary innovation. Failure to flex means failure of the whole enterprise: mobile game coders will often fail to find the discipline to create an ambitious mobile application that works reliably. Symbian coders will fail to see that J2ME is an adequate platform, and that broad platform reach can be available through J2ME. Those steeped in search might fail to adapt to the limitations and opportunities of small-format presentation. And IN-experienced engineers can be too much in the telco mindset to integrate with anyone else with a more entrepreneurial world view. If the executive leadership of such an enterprise cannot encompass all that enough to evaluate if it is coming together or not, chances for success are diminished. If the participants reach only a minimal level of compatibility and fail to reach for ambitious goals in every distinct area of competency, the result will be easily matched and exceeded by competitors.
It can all be boiled down to four points:
- Only a small subset of ventures require innovation and audacity across multiple disciplines, so it isn’t a familiar problem.
- Apart from recognizing that some of these ventures are execution plays, VCs find the value of interdisciplinary innovation hard to measure.
- The participants in these ventures have to be inquisitive about each other’s domains of knowledge, and be able to seek innovation near those boundaries. The more dimensions to the problem, the less likely it is this will happen.
- The leadership, at the stages of founding, funding, and operating the enterprise have to be cognizant of their situation and act to make an interdisciplinary venture work.
But even simplified to this degree, interdisciplinary ventures are more complicated, and therefore more risky, than simpler plays. They are all the rarer in that, even when they are recognized it may only be to avoid them.
Posted by
Zigurd
at
7:02 PM
0
comments
