iPhone 3GS from AT&T. Free ShippingI've been an IT industry analyst for almost 10 years. I've seen many technologies come, go, or fail to even arrive in the first place. However, during that time, a few techs have emerged that play a big part in fundamentally defining how businesses do computing. Most first emerged prior to 2000, but it has been during the past decade that they've truly changed things.
1. x86 processors were already well entrenched in corporate computing by the end of the 1990s, especially in their role as the "(In)tel" part of "Wintel" servers running Windows NT. However, their dominant designer and manufacturer, Intel, was heading in a different direction to handle the inevitable transition to the 64-bit processors and operating systems needed to keep pace with growing memory requirements.
That new direction was Itanium, a clean sheet processor design by Intel and Hewlett-Packard intended to get away from all the legacy features of x86 and--not incidentally--cut the x86-compatible processor makers out of the picture. The Itanium family remains with us but primarily as a processor for high-end HP servers. It was AMD that first added 64-bit extensions to x86 but Intel felt compelled to follow. And it was this backwardly compatible version of x86 that is the mainstream 64-bit server processor, not Itanium.
2. The other big processor story of the decade is multicore. Near the end of 2000, Intel introduced the Pentium 4 processor based on the NetBurst microarchitecture. It was intended to eventually hit about 10GHz. In fact, it never got beyond 4GHz and came to be viewed as the last gasp of performance scaling through frequency.
AMD introduced its first multicore x86 Opteron processors for servers in 2005 which helped it gain market share for a time while Intel made major changes to its development plans and processes. IBM and Sun also aggressively pursued multi-core in their RISC lines. Specialty processors such as Azul's Vega and Tilera's TILE lines went even more radically multicore. In short, frequency is largely dead as a path to higher system performance, which will require a combination of more cores and specialty accelerators working in parallel.
3. When I first met Diane Greene, co-founder and then-CEO of VMware in the fall of 2000, VMware was already selling a product to developers that let them run multiple operating systems on a single workstation. But Diane was in town to pitch me on something new, a pair of new server virtualization products--GSX and ESX Server--that made it possible to consolidate multiple workloads on a single physical server and to provision them more quickly.
The basic concept goes all the way back to IBM's involvement with early developments in time-shared computing in Cambridge, Mass., during the early '60s. And all the RISC/Unix vendors of the time had their own approaches to slicing and dicing servers. However, it was VMware that brought server virtualization to the masses. Its product ran on standard x86 servers and it provided a way to consolidate workloads right at a time when IT purchases were dramatically slowing and anything that could save money was in vogue.
EMC bought VMware in 2003 for $635 million, a figure which it's hard to believe today was widely viewed as an overpayment. Today, server virtualization--an area where VMware remains the 800-lb. gorilla despite Microsoft's entry--continues to fundamentally change the way IT departments think about operating their data centers. Virtualization also underpins much of cloud computing, another major developing trend.
4. Linux and other open source were a big part of the dot-com and service provider build-out of the late 1990s.
But enterprises? Not so much. This 2001 research note had to argue that Linux was, in fact, ready for serious production use. And, whether "ready for the enterprise" is a meaningful question in the abstract, the fact remains that the Linux 2.4 kernel was widely regarded as the first version deserving of that description and it wasn't released until mid-2000. IBM began its big Linux push at about the same time.
Thus, I'd argue that it's been this past decade and not the prior one that has seen Linux and open source truly become a pervasive part of computing. That's not to say that open-source has replaced all other software. But it has heavily influenced how companies do development, engage with user and developer communities, and provide access to their products--even when the software in question is proprietary.
5. My last entry has the greatest overlap with the consumer space. That's not a coincidence, given that mobile devices are a very visible example of what Citrix CEO Mark Templeton calls the "comsumerization of IT."
Mobile devices encompass at least a couple of different things. The most obvious entrant is probably the smartphone--first in the guise of the BlackBerry and more recently the iPhone. We are now at the point where you can carry a bona-fide computer in your pocket, complete with GPS and other sensors, and can run applications that you install. As my colleague Jonathan Eunice has noted, it really is a transformational experience relative to, say, my older Treo. It also represents the reality of the modern smartphone that, for many, it's increasingly about mail, texting, and social media and not, you know, phoning.
However, the smartphone doesn't deserve all the limelight. The noughts have also seen the laptop computer transform. I'm not talking about the form factor so much--although Netbooks have gotten their share of attention. Rather I'm talking about the way that we can use them.
I've had laptops since the 1990s but it wasn't until about 2001 that conferences and other venues started to put up Wi-Fi networks. They worked fitfully (some things haven't changed as much as we might like), but this was the beginning of the connected laptop rather than the merely mobile laptop.
And that's why I see the smartphone and the laptop as part of the same mega-trend. It's not about a particular form factor or usage model. It's about (almost) always being connected to applications that increasingly live largely in the network.
The nice thing about standards is that there are so many of them.
This old saw is arguably less true than in years past. Today, for a lot of reasons, there's more pressure to reach agreement on one way to do a certain thing. (Think the HD DVD vs. Blu-ray debacle for an example of what happens when vendors can't agree on a single approach.)
Standards aren't a single thing. Some have been blessed with the appropriate incantations by some official or quasi-official body. Others come from an industry consortium. And still others are "de facto" (or at least began life that way)--the result of a dominant company or just a default way of doing things.
The purist will argue that just being widely used doesn't make something a standard. I agree up to a point and only use the "standard" term in this case for things for are truly ubiquitous. Contrariwise, a rigorous formal ratification process is no guarantee of success.
But some standards do win big and become part of just how IT gets done. Here are some of them.
Like many other successful standards, Ethernet has remained a fixture in local area networks for so many years in part by adapting to many successive waves of technology. First developed in the famous Xerox PARC labs in the mid-1970s, it initially ran over coaxial cable but soon moved to twisted pair cable with the 10 Mbit/second generation. 10 Gbit/second Ethernet is now starting to roll out along with a variety of additions to the specification that make it more suitable as a high-performance unified fabric.
Ethernet's initial success resulted in no small part from coordinated standardization efforts beginning in the IEEE. This helped it beat out alternatives, most notably IBM's Token Ring. Over time, Ethernet's ubiquity and the cost benefits provided by this volume helped it largely stave off server interconnect challengers. InfiniBand has had wins in high-performance computing and certain other clustering applications, but it didn't displace Ethernet as a "server area network" as early promoters had hoped.
PCI, Peripheral Component Interconnect, had its beginnings as an Intel-developed bus for connecting internal cards within systems. The version 1.0 spec came out in 1992. Given the ubiquity of PCI these days, it's easy to forget that it only replaced a plethora of other busses both standardized and proprietary in x86 and, later, large Unix servers based on other processors over the course of nearly a decade.
Nor was the process steady. Although PCI was initially introduced in part to replace the VESA Local Bus for graphics cards--which it eventually did--PCI was itself replaced by AGP (Accelerated Graphics Port) for a time prior to the PCI Express generation.
PCI Express makes for an interesting case study in the marketing of standards. With technology bumping up against the limits of parallel I/O busses like conventional PCI, the Arapahoe Working Group--spearheaded by Intel--started pushing a new serial interconnect standard in about 2001. Arapahoe's success was by no means pre-ordained. AMD's HyperTransport was one alternative among several.
Arapahoe required hardware that was largely different from PCI but it was compatible with PCI's software model in a number of respects. And this was enough to get Arapahoe adopted by the keeper of the PCI standard, the PCI-SIG, and get the SIG's imprimatur on what would now be called PCI Express. And that helped make it the obvious heir to PCI. Names matter. (Here's a more detailed accounting of PCI Express and its history.)
It's easy to forget just how painful it could be, in the years before USB (Universal Serial Bus), to connect external peripherals to a computer system. RS-232, a long-used and successful standard in its own right, was the most common way. It was also a way that could easily devolve into examinations of cable pin-outs, interrupt channels, and memory addresses.
USB was a cooperative effort by a group of large technology vendors who founded a non-profit corporation to manage the specification. Version 1.0 was introduced in 1996. Now up to version 3.0, USB has become the standard way to connect external peripherals to PCs; it's also commonly used on servers for devices such as printers.
There's a spec for wireless USB but, like other standards intended to connect peripherals to computers wirelessly, it's never taken off. The current such "personal area network" getting the most buzz is My WiFi from Intel.
USB's primary competition has been FireWire, Apple's name for IEEE 1394. Unlike USB, it does not need a host computer and is faster than the USB 2.0 generation. However, it didn't catch on widely in the computer industry outside of Apple (which is phasing it out in favor of USB) and video equipment.
TCP/IP refers to the combination of two protocols: Transmission Control Protocol and Internet Protocol. Together, they are among the most important pieces of software underpinning the Internet which transitioned to using TCP/IP in 1983. Work on TCP began under the auspices of the Defense Advanced Research Projects Agency (DARPA) a decade earlier but, along the way, the software stack was re-architected to add IP as the early Internet grew.
Like many of the Internet's building blocks, TCP/IP was firmly entrenched before commercial interests got involved to any significant degree and, indeed, before most of the world at large had any real notion of the Internet's existence. The general public came to know the Internet through the World Wide Web, an outgrowth of Tim Berners-Lee's development of HTML at CERN, in the 1990s. Thus HTML, as well, is a key standard.
At the time that TCP/IP was gaining momentum, the International Organization for Standardization (ISO) spearheaded a large project to standardize networking. The "OSI model" remains the standard way to think about layers of the networking stack. If you talk about a switch being "Layer 4," you're using OSI terminology. But the specific protocols developed to go with the model were never widely used. (TCP/IP largely maps to the layers defined in the OSI model.)
The x86 architecture is perhaps the canonical example of a de facto standard driven primarily by a single vendor: Intel. Microsoft Windows is also in the running, but it was very arguably x86's ubiquity in a segment of the market open to relatively low-cost packaged software that made the rise of Windows possible. Over the past decade, AMD has also driven x86 innovations--most notably 64-bit extensions. However, it was Intel that had the biggest hand in shifting the industry from a structure in which each company did everything from fabricating processors to writing operating systems to developing databases to one in which different companies tend to specialize in one part of the technology ecosystem.
x86 emerged as a dominant chip architecture for a variety of reasons. IBM designed Intel's 8088 into the first important business PC. It got this win and others at a time when the world was rapidly computerizing. And Intel optimized itself to ride key technology trends while divesting itself of businesses, such as memory, as they commoditized.
Finally, here are a few others that could make a list like this one:
Wi-Fi played a big role in making personal computers more mobile--which is why Intel pushed it so hard.
VGA is the computing video standard that finally helped merge a rather splintered landscape and had a good long reign. (The latest video interconnect trend is a shift to HDMI--representing a coming together of computing and consumer electronics standards.)
SCSI was the first storage interconnect to merge in a big way a disparate set of existing connection schemes, both proprietary and more or less standardized. However, storage has remained an area where different standards are used for different purposes. That's changing to a degree with SATA, however, which we now see in both PCs and data centers.
Intel's James Reinders is an expert on parallelism; his most recent book covered the C++ extensions for parallelism provided by Intel Threaded Building Blocks. He's also the Director of Marketing and Business for the company's Software Development Products. In Part 1 of our discussion at the Intel Developers Forum in September we talked about how to think about performance in a parallel programming environment, why such environments give developers headaches, and what can be done about it.
Here, in Part 2, we move on to cloud computing, functional and dynamic languages, and what needs to happen with computer science education.
Few wide-ranging conversations these days would be complete without at least a nod to cloud computing which Reinders views as very much connected to the matter of parallel programming.
Cloud computing is parallel programming. You're solving the same problem. In fact, someone that's good at decomposing a program to run in parallel on a multicore or on a supercomputer... the same thought process is necessary to decompose a problem in cloud computing. What's different in cloud computing is that the cost of a connection or a communication between two different clouds is so high. You really need to get it right. It works best when a little message is sent, does an enormous amount of computing, and gets a little message back.
Data parallelism tends to be very fine-grained.
Task parallelism like we see with Cilk and Threaded Building Blocks is a little bit more coarse.
Cloud computing has to be very very coarse-grained parallelism.
But there's something common about how you have to think about it.
The tools that will let people do cloud computing, express a problem in cloud computing, may eventually just map onto a multicore.
The granularity that Reinders discusses refers to how small a chunk of computing can be, given the cost and latency of communications. Within a single processor, communications bandwidth is high and latencies low, so software can afford to perform a relatively small task and then synchronize the results. (Although moving large amounts of data can still be relatively "expensive" which is why data parallelism can be finer-grained than task parallelism; see Part 1 for further background on data parallelism.)
By contrast, external communication networks have limited bandwidth and are relatively slow--on the order of four or five orders of magnitude slower than communications within a system. Therefore, tasks have to be parceled out in relatively large chunks that, ideally, don't have to be packaged up with a significant amount of local data.
Next up was education. Here, Reinders' basic message was focusing on the theory before diving into the implementation details. I suspect that this highlights one of the key challenges: Parallel programming tends to require a solid grasp of programming theory and doesn't lend itself particularly well to just "hacking around" in the absence of that grounding.
I've been doing a lot in the area of teaching parallelism. What a lot of people think of right away is teach them locks, teach them mutexes [algorithms to prevent the simultaneous use of a common resource], teach about how to create a thread, destroy a thread. That's all wrong. You want to be talking at a higher level. How do you decompose an algorithm? What is synchronization in general? Why does it exist?
Things I would hope undergraduates would learn are parsing theory, DAG representations [a tool used to represent common subexpressions in an optimizing compiler], database schemas, data structures, algorithms. All these are high level, not things like [the programming language] Java. Parallel programming's like that too. You get hands-on touching the synchronization method or whatever but you want to teach the higher level key concepts.
Some people it's going to be more in-tune with their thinking but you try and teach it to everyone.
Given that most of today's languages weren't expressly designed for parallel programming, discussions about parallelism often turn to new programming languages. This means functional languages most of all but can also involve dynamic or scripting languages which generally handle more low-level details under the covers than do Java or C++.
Functional languages don't lend themselves to easy, or easily comprehensible, description. A common shorthand is that "Functional programming is a style of programming that emphasizes the evaluation of expressions, rather than execution of commands." But that probably doesn't help much if you don't already know what it is. As for Wikipedia's entry, Tim Bray--no programming slouch--called it fairly impenetrable. (Perhaps you begin to see the problem.)
A couple of things I'm interested in functionals for. We don't wake up one day and everyone uses. It's sequential semantics again and sequential semantics appeal to people and functional languages don't have them. But some people eat them up.
And they solve amazing problems. You can code things up in them that are much easier to understand than if they are written in a traditional language although they can be cryptic or terse to a lot of programmers.
Erlang [a functional language] has gotten a bit more and more usage. Maybe it is creeping in. It's not going to take over the world overnight but it seems like the one that might stay around. May be talking about it 20 years from now and saying, yeah, Erlang's been around for 25 years. It might be accepted as a language. It may have legs.
But even Java. [Unlike Erlang,] It appealed to people who programmed in C and C++; it didn't challenge them to think differently. And because of the strict typing and stuff it helps [the enterprise developer] to deploy certain types of apps.
Python [a dynamic language] is interesting. It is so popular with a lot of scientists. It's on my short list of things, where if we can figure out where to partner or extend some of the things we're doing, Python's on my short list of languages that we want to help with parallelism. Maybe some of our Ct technology would apply there. We'll see if other people agree with us. Think the concepts we're talking about are pretty portable.
Finally, we concluded our discussion with hardware.Are there opportunities at the hardware and firmware level with memory subsystems or with specific technologies such as transactional memory? Sun Microsystems was very interested in transactional memory in the context of its now canceled "Rock" microprocessor. The basic concept behind transactional memory is to provide an alternative to lock-based synchronization by handling concurrency problems as they occur at a low-level rather than having the programmer protect against them all the time.
The best solutions tend to not be silver bullets so much as incremental. Nehalem [Intel's latest microprocessor generation] in a way probably helped us more than anything in recent memory because we moved to the QuikPath interconnect and moved bandwidths up and latencies down. Larrabee [a many-core Intel microprocessor still under development] may pave the way with some innovations in interconnects. I think there may be some refinements needed. Interconnecting the processors is a classic supercomputer issue.
Transactional memory has slammed up against a very tough reality which is that hardware always wants to be finite; software solutions wants to be infinite. Think there's something there.I think the people looking at transactional memory have started to make observations about locks that may end up being useful. It's funny. The mission of transactional memory is to get rid of locks but the more they looked at it the more they understood about how locks behave. There might actually be possibilities to make locks behave better in hardware.
Can we do the hardware a little differently? Not the sexiest thing in the world. But as we move from single-threaded to multi-threaded what complications are we creating things [that the hardware can help with]?
Even if you don't subscribe to the more extreme views of programming and software being in a crisis because of the move to multi-core, we're clearly in a transition. New tools are needed and programmers will have to adapt as well, to at least some degree.
Multicore processors are here to stay and the number of cores that we'll see packed onto a single chip is only going to increase. That's because Moore's Law is only indirectly about performance; it's directly about increasing the number of transistors. And, for a variety of reasons, turning those transistors into performance today largely depends on cranking up the core count.
There's a downside to this approach though. Programs that consist of a single thread of instructions can only run on a single core. This in turn means that they're not going to get much faster no matter how many cores a chip adds. Running faster means going multi-threaded--splitting up the task and working on the different pieces in parallel. The problem is that programming multi-threaded applications introduces complications that don't exist with single-threading.
These complications and ways to overcome them was the topic of my conversation with James Reinders at the Intel Developers Forum in September. Reinders is the director of marketing and business for Intel's Software Development Products. He's an expert on parallelism and his most recent book covered the C++ extensions for parallelism provided by Intel Threaded Building Blocks.
In part 1 of this discussion we talked about how to think about performance in a parallel programming environment, why such environments give developers headaches, and what can be done about it.
Reinders began by noting that developers fall into roughly two groups when it comes to parallel programming: those who are still concerned about ultimate performance even in a parallel world and those who are just looking for a way to deal with it at all.
The challenge is understanding what we're trying to introduce, how to use parallelism, but with programmer efficiency. Because programmers don't need yet another thing to worry about. There's plenty of those out there.
And we need to be a little more relaxed about the performance. The people who start asking me about efficiency in every last cycle used and such--I characterize them as people we need to talk to more about our high-performance computing-oriented tools that give you full control. And other people are "I don't even know how to approach parallelism." I think there is a different set of ways to talk about the problem.
The problems with this second group comes down to the fact that most programmers are used to dealing with something called "sequential semantics." A detailed description of programming semantics is a complex computer science topic but, at a high level, sequential semantics means more or less what it sounds like it sounds; instructions follow one after another and execute in the order that they are written.
If you store the number "1" in variable A, then store the number "2" in variable B, and then add them together in a third instruction, you can be confident that the answer will be "3." It won't depend on timing vagaries that might have caused the addition to happen before the stores. Most people start out programming sequentially using languages designed for that purpose.
Parallel programming, on the other hand, introduces concepts like data races (the answer is dependent on the timing of other events) and deadlocks (in which two threads are each waiting for the other to complete so that neither ever does). Here's Reinders:
If you've ever managed and got a bunch of people working on a project together, one of the headaches you get is coordinating with each other. What did Fred say to Sally? They're doing things out of order or whatever. Parallel programming can give you that same sort of headache.
The programming terminology you'll hear the compiler people use is "sequential semantics." One of the interesting areas is what can we do if we ensure sequential semantics. We recently acquired a team in Massachusetts who were working for a company called Cilk Arts.
Our hope is that Cilk can do a subset of what Threaded Building Blocks [TBB] can but preserve sequential semantics. We think we can do sequential semantics, do a subset of what TBB does, since we're introducing keywords into the compiler--that has some disadvantages because it's not as portable--but we think we might be able to magically give you sequential semantics and not give up performance. That's a big if.
Now why would we invest in that?
Because there are a lot programmers who have been getting along just fine with sequential programming. But when you tell them to add this or that for parallelism, a big thing that trips them up is that you no longer obey sequential semantics; you have more than one thing running around and you get data races, deadlocks, and it doesn't feel comfortable.
Now some people will argue that you need to do these things to get good performance. We have the feeling that in some cases you don't need to take that big of a leap to get pretty good performance.
And no one's going to criticize your app on a quad core for being only 70 percent efficient.
From there we moved on to data parallelism which focuses on distributing data across processing elements. It contrasts with the task parallelism that we commonly associate with the term parallel programming. Pervasive DataRush is one commercial product based on a data parallelism model. APL, the language with the strange symbols (for those with long memories), is often considered the first data parallel language. There have been a variety of others, often extensions to more conventional languages like C and FORTRAN, but none were widely used.
The other thing we're looking at is data parallelism. And that's where we acquired the RapidMind team and combined them with our Ct [C for Throughput Computing] team.
Data parallelism just takes it one step further. Data parallelism is all about the parallelism in the data. So you're talking about the data when you program.
And once you start talking about the data, the tools underneath can move the data around. Leaving the data management up to the programmer [as with Cilk and TBB] turns out to be a terrific headache. This applies equally to a cluster where they don't share memory or a GPU and a CPU in the same system.
But a language like RapidMind or Ct can address that problem. And CUDA and OpenCL can too [frameworks primarily oriented towards heterogeneous processing that uses graphics cores for computing tasks] but RapidMind and Ct are at a much higher level of abstraction which means that we're betting on the idea that we can attract more developers and give up some efficiency.
Part 2 of our conversation will cover cloud computing, functional and dynamic languages, and what needs to happen with respect to programmer education.
There are many different technology adoption models out there. Geoffrey Moore's curve--the one that uses terms such as "Early Adopters" and "Late Majority"--is a common one. And different technologies end up getting adopted at strikingly different rates. This fascinating chart from The New York Times shows how the telephone made its way into U.S. homes only over a span of many decades while the VCR went from rare to commonplace over about a single 10-year stretch.
In general, new technologies are permeating the market faster than ever before. Still, the length of time it takes for even an ultimately successful innovation to become commercially important is routinely underestimated by lots of industry watchers. I've been guilty of this myself.
One issue is that many of us in the IT ecosystem are early adopters by nature. We're enthusiastic about the new coolness for its own sake, not just for what it's capable of. By contrast, the ultimate buyers are often more conservative and mostly want technologies that have already proven themselves. It's a potential that we as analysts try to guard against, in part by speaking with different types of end users.
Another issue is that new technologies are often more interesting in combination with other pieces than they are in isolation. To use the old cliche, the whole is greater than the sum of the parts. However, the corollary is that it takes more work and more time to bring that combination into being than it does just one component. Frederick Brooks discussed this reality in the context of bringing the IBM System 360 to market in his widely read "The Mythical Man-Month".
I bring up this topic because of something that caught my eye in a Web 2.0 Summit presentation by Mary Meeker of Morgan Stanley. She devoted a large chunk of her presentation to mobile trends, beginning with a slide that stated "Mobile = Incremental Driver of Internet User / Usage Growth." She went on to say that "Mobile Internet usage is and will be bigger than most think."
This computing growth includes Apple. She stated that "Near term, Apple is driving the platform change to mobile computing. Its mobile ecosystem (iPhone + iTouch + iTunes + accessories + services market share / impact should surprise on the upside for at least the next 1-2 years." However it also includes a rich set of other devices including automobile electronics and home entertainment devices. In some respects, this is the "Internet of things" as Sun Microsystems CTO Greg Papadopoulos has called it. (Although as Richard MacManus over at ReadWriteWeb suggests, the full Internet of things, including RFID sensors and the like, is something more expansive.)
The "secret sauce" in this growth? Location-based services. Meeker quoted Mathew Honan, of Wired magazine, who wrote: "Simply put, location changes everything. This one input - our coordinates - has the potential to change all the outputs. Where we shop, who we talk to, what we read, what we search for, where we go - they all change once we merge location and the Web."
What caught my eye about all this was that I remember all the enthusiasm over the imminent arrival of the mobile Web back during the first Internet build-out about a decade ago. Here's a typical press release from a company named Optus in November 2000: "Mobile phone users can locate a close-by restaurant, chemist, bank or cinema now that Cable & Wireless Optus has launched Australia's first range of sophisticated location-based services on its Wireless Application Protocol (WAP) service, Optus Networker."
There were many such claims at the time and many proclamations that "place" was the Next Big Thing.
Ultimately it appears the proclaimers were right. But it took a while. It arguably took the second or third iteration of iPhone for applications that make use of the user's location in smartphones to take off in a big way. And thereby make the promises of press releases of the year 2000 a mainstream reality.
Some of it is just technological maturity of the device and the network. A mobile browser that can access the "real" Web with reasonable fidelity and performance rather than being restricted to a dumbed-down mobile Web turned out to be one major piece.
Key too was a development environment that made it possible for many casual developers to create applications and not just a few working closely with a handset maker.
The vast amounts of data created over a number of years through various types of social media is pretty important as well. We don't mostly find nearby restaurants through formally curated data; we find it through Yelp.
In short, the rich mobile experience isn't about one thing but many. And aligning the pieces always takes time.
At the end of July, Sun posted a screenshot from "Project Renaissance," an effort aimed at creating a new user interface (UI) for OpenOffice. The prototype includes a "ribbon" UI in the vein of the one that Microsoft introduced for Office 2007. Perhaps unsurprisingly, many of the user comments were critical and devolved into Microsoft bashing.
I never got the ribbon-hate myself. Well, OK, that's not really true. A lot of people don't like change and a lot of people like ragging on Microsoft for whatever reason.
However, I always found it more than a bit ironic that a lot of the same people who routinely claim that Microsoft doesn't innovate were, in this case, suggesting this was a good opportunity to get users moved to OpenOffice where they could avoid such a disruptive change.
For my part, I found the ribbon took some getting used to but now I like it for the most part. Like other Microsoft products, I find the design a bit garish but the mechanics generally work well enough for me.
So I don't see anything wrong, at least in principle, with OpenOffice introducing a ribbon interface. There are a lot of broader issues around OpenOffice and its future. These include Oracle's acquisition of Sun, fragmented development by a variety of companies, and the lack of a clear mission at the level of the project as a whole. Part of the problem is that while a free/cheap, "good enough" word processor may be something that a lot of end users want, that's not really a business for anyone. For its part, IBM has used OpenOffice to tie into document-related business processes. But that's about something fundamentally different from OpenOffice, the word processor.
Beyond the question of what OpenOffice wants to be when it grows up, though, there is something specific about the prototype that bothers me.
To understand why, it's important to understand what Microsoft was trying to accomplish by introducing the ribbon. For the full story, I highly recommend this video by Jensen Harris of the Office User Experience Team from MIX08. However, in a nutshell, the ribbon essentially ripped out years of accumulating menu items and other UI elements and replaced them with something designed from the ground up. It was a bold choice but the nature of the problem meant that it didn't lend itself to a piecemeal fix--indeed, piecemeal fixes were what caused the problem in the first place.
The OpenOffice prototype, on the other hand, appears to add a ribbon while leaving the menu system extant. This way lays user interface madness even if it does provide more choices. Good design is often (indeed is usually) about constraining choice rather than expanding it.
(For a different perspective, see the CNET piece by Dong Ngo.)
Standards evolve in a lot of different ways. However, broadly speaking, they fall into two main buckets: de jure and de facto (to use the Latin-derived legalese). By law and by fact.
In high tech as elsewhere, it's often a matter of historical accident and political maneuvering that determines which approach wins out in a particular area of technology. And it can be a high-stakes game for the companies involved, with big players often seeking to position their approach as a "standard" even if it's only standard in the sense of being ubiquitous (think Microsoft Windows) while the smaller guys tend to favor approaches blessed by standards bodies or at least industry corsortia.
In cloud computing, we're seeing almost all the forms of standards-making coming into play with the primary goal of promoting interoperability among different cloud service providers and between private and public clouds.
On the de jure side, the most significant standards-making effort is taking place under the auspices of the Distributed Management Task Force (DMTF), an established organization in the management standards space. AMD, Cisco, Citrix, EMC, HP, IBM, Intel, Microsoft, Novell, Red Hat, Savvis, Sun Microsystems, and VMware announced in April 2009 (PDF) that they would comprise the board for an Open Cloud Standards Incubator within the DMTF.
If you were to observe that none of those companies currently have a big play in public cloud infrastructure, you would be correct. Microsoft has its Platform-as-a-Service Windows Azure play, and a number of those companies are very active in working with enterprises to build internal cloud-style IT, but none have an Infrastructure-as-a-Service (IaaS) offering in the vein of the conspicuously absent Amazon.
And it's Amazon Web Services (AWS) that has clearly emerged as the de facto standard for IaaS. The fact that Amazon is one of the first vendors that comes to mind in just about any discussion of public clouds is one indication. Another is the growing ecosystem of companies like RightScale that add additional features to AWS--not uniquely, but first and foremost. We now even have an open-source project and company, Eucalyptus, that lets organizations implement their own clouds that are compatible with many AWS services.
Now one of Amazon's competitors, Rackspace, is taking yet another approach to promoting its implementation as a standard. It's open-sourcing the specifications for its Cloud Servers and Cloud Files API under the Creative Commons 3.0 Attribution License. It also has made available its Cloud Files language bindings for Java, PHP, Python, C#, and Ruby under the MIT license.
The Creative Commons license that Rackspace is using lets users both share and change the work so long as they provide attribution to the creator, in this case Rackspace. The MIT license is a very permissive license in the vein of BSD that allows essentially any use of the code including its use within proprietary software.
Rackspace has emerged as a major player in public cloud infrastructure. Cloud Servers competes with Amazon EC2 and Cloud Files with S3. It also has a product called Cloud Sites, based in part on technology from its Mosso acquisition, that is more of a PaaS offering with dynamic scalability (but that's not part of this announcement).
This announcement doesn't fundamentally change the landscape. However, it does give an already well-established IaaS vendor a point of clear differentiation from its biggest competitor.
We've all heard the rant. With e-books, there's no paper, printing, transportation, and so forth. So why should an e-book still cost $9.99 (typical for Kindle) or even more?
The idea of e-books being cheaper makes a lot of intuitive sense. If everything you physically hold in your hand and everything it took to deliver that physical good to your hand can be converted to a few megabytes worth of electrons, surely the cost of the book must be dramatically lower than a typical hardcover--and the price should reflect that fact.
The problem is that the costs aren't nearly as much lower as you might believe. Here's one breakdown from Money magazine for a hardcover bestseller by way of Scott Laming of BookFinder.com Journal:
Based on a list price of $27.95
$3.55 - Pre-production - This amount covers editors, graphic designers, and the like
$2.83 - Printing - Ink, glue, paper, etc
$2.00 - Marketing - Book tour, NYT Book Review ad, printing and shipping galleys to journalists
$2.80 - Wholesaler - The take of the middlemen who handle distribution for publishers
$4.19 - Author Royalties - A bestseller like (John) Grisham will net about 15% in royalties, lesser known authors get less. Also the author will be paying a slice of this pie piece to his agent, publicist, etc.This leaves $12.58, Money magazine calls this the profit margin for the retailer, however, when was the last time you saw a bestselling novel sold at its cover price.
One way to look at this is to look at the percentage of the list price that printing represents. That's 10 percent--plus at least a chunk of the wholesaler line item. So let's call it 20 percent in all.
But, as noted, given that books generally sell at a discount off list, I find it more intuitive to look at this the other way. Start at zero and add cost and profit line items. In the example, the typical volume retailer is often making far less than the $12.58 figure would suggest. A 40 percent discount brings it down to only $1.11; hardcover bestsellers are a sort of loss-leader for retailers.
Pre-production. Other things being the same, there's no reason this goes down with an e-book. Arguably it's a bit lower if something is sold solely as an e-book--perhaps a bit less design work and proofing related specifically to the physical nature of a book--but it's actually likely a bit higher if we're talking about having both physical and digital versions--as would be the typical case today.
Now some, such as blogger Aaronchua, argue that this just shows that traditional publishers "have not changed their operating structure to leverage on the new economics brought on by the Web."
However, as noted in discussion of the prior piece, these functions are not just costly overhead. "After the book's in the publishing house, it is usually reviewed by like up to 5 editors who give their opinion before it's handed over to one editor who they believe is the best for it. You then get an editor, who through multiple revisions helps the author get the book to a better standard and quite often to more closely resemble the author's original idea."
Now, perhaps the whole process is too heavyweight. But how many of us have read a book and thought to ourselves that "it really needed an editor." Most of us, I'd say. You can skimp here but the results often show it.
Marketing. Again, there's no inherent reason why the dollar amount changes. Many aspects of the marketing process probably change if we posit an all-digital world. But social media and other forms of viral promotion are not a panacea that magically replaces book tours, professional publicity work, and so forth. Sure, you don't need to do any of this but you don't need to sell many books either.
Profits. Let's be generous and cap the costs there. In practice, there are going to be some costs related to digital delivery that someone is going to have to shoulder along the line, but ignore that.
If we're going to sell the book for $9.99 net of any discounts, that leaves us with $4.44 to split between the retailer and the author. Compare that to $4.19 for the author in the printed book example and something between about $1 and $10 for the retailer. So a $9.99 e-book in this example leaves less money after costs than the hardcover does.
This may be made up by higher volumes to some degree. However, as Tim O'Reilly noted in a 2007 post:
I think that the idea that there's sufficient unmet demand to justify radical price cuts is totally wrongheaded. Unlike music, which is quickly consumed (a song takes 3 to 4 minutes to listen to, and price elasticity does have an impact on whether you try a new song or listen to an old one again), many types of books require a substantial time commitment, and having more books available more cheaply doesn't mean any more books read. Regular readers already often have huge piles of unread books, as we end up buying more than we have time for. Time, not price, is the limiting factor.
The economics of selling back-catalogs may also be different. Pre-production costs are, almost by definition, fixed. They're incurred before the first book can go out the door. Marketing is also primarily a fixed advance cost. (Although the size of budgets will be tuned to expected sales--unknown authors with no track record shouldn't expect massive advertising and publicity campaigns.)
So once those costs have been incurred--and hopefully recouped--in more or less the usual way through the first couple of years of a book's life, it may make sense to offer a discounted digital edition given that it doesn't incur the cost overhead associated with lower volume "long tail" sales.
(In principle, you could argue that the same logic applies to the pricing of digital editions at any time in a book's lifecycle. However, in practice, a $5 e-book of a new release would cannibalize the more profitable print edition.)
I know this post went into a lot of detail, but when you're talking about business models and pricing, it is important to actually run the numbers. One can dispute fundamental assumptions behind those numbers of course, but at least they give a starting point.
In this case, they show that--if you want the same level of professional preparation and promotion associated with a typical printed book--the $9.99 e-book price that a lot of people grumble about is probably pretty near the floor.
Some pieces essentially write themselves. This is one of them.
I received the following e-mail this morning with the subject "BSA Launches Faces of Piracy Campaign." It came from the Fd.com domain, which I assume is the Business Software Alliance's public relations firm for this campaign.
We've all been following the events of the past week of the pirates off the Horn of Africa. Piracy takes many forms, some more violent than others. I wanted to let you know that the Business Software Alliance is launching a new campaign today "Faces of Internet Piracy" that shows the real-life impact of software piracy--from hundreds of thousands of dollars in fines to jail time. Click on the picture below to learn more about the campaign...let me know if you're interested in writing about this.
Whatever you may think of the BSA and its tactics in general, this has got to be one of the most tone-deaf and cynically opportunistic PR pitches I've seen for quite some time.
It's one thing to figuratively equate piracy with making digital copies of software, music, movies, or books. We can debate endlessly whether such actions are truly stealing or not. But that's not the point.
It's that to literally and deliberately equate the two in the wake of pirates taking a ship's crew hostage and the US Navy subsequently killing three of the attackers...Well, words fail me.
I've been critical of past Microsoft advertising.
The low point may have been calling customers and potential customers dinosaurs for not upgrading to Office 2003.
But Microsoft advertising, in general, has been at best inconsistent, in that it has often spoken to the needs and desires of Microsoft--as opposed to the needs and desires of its customers. (In all fairness, this is hardly a problem unique to Microsoft's advertising or, indeed, to the advertising that comes out of the the tech industry overall.)
But the company's latest, from the Crispin Porter + Boguksy agency, nails it.
As Philip Elmer-DeWitt summarizes:
Her name is "Lauren," and she's making the Apple (AAPL) guys nuts...She's the young, hip, Volkswagen-driving redhead who stars in the latest Microsoft (MSFT) TV campaign. Told that if she can find a 17-inch laptop for under $1,000, she can keep it, Lauren ends up--to the Mac aficionados' dismay--with an HP (HPQ) running Windows Vista.
The message? Sure, Macs are fine. But who can afford one in these times?
The Apple fan club is up in arms. A lot of the reaction is pretty silly and dwells on the fact that the star of the spot is actually an actress and that the events shown are staged. Shocking and surprising, I know.
As for whether the comparison of the 17-inch Apple and HP laptop is completely fair and apples-to-apples? Well, of course it isn't. We're talking advertising here. There has to be a degree of credibility, yes, but absolute objectivity? Hardly.
Best line: the sighingly delivered, "I'm just not cool enough to be a Mac person."
From an advertising perspective, the commercial does have a weakness. It essentially sets the Mac up as the aspirational brand, the laptop that would apparently be Lauren's first choice, if it weren't for its cost. This ad wouldn't fit especially well with a more free-wheeling era.
But this is not that era. And a value message strikes me as a good one for Microsoft in this context, especially as delivered in a light, humorous, and gently hipster-mocking way.
