 | Level: Intermediate Joe Marasco, CEO, Ravenflow
15 Jul 2002 from the Rational Edge: This article proposes a simple solution for upgrading the software in devices such as cell phones and PDAs that are lightweight, handheld, and wireless.
In this issue, I address the pesky problem of upgrading software in a certain class of device: those that are handheld, mobile, wireless, and fairly lightweight. Amongst them we find cell phones, personal organizers, GPS receivers, digital cameras, and various combinations thereof. They all have embedded software, some programmable memory, and batteries. They may or may not communicate with other devices.
This class of device is increasingly important, and its members are proliferating, for at least two reasons. In the first place, every product that is designed for personal portability tends to get smaller over time; and as the benefits of their functions (for instance, the transferability of digital photographs) become widely understood in the marketplace, their decreasing size makes them more attractive as well. In the second place, we are constantly seeking ways to free ourselves from detestable "tethers." Wireless communications does that nicely, since there's no landline to fuss with; and batteries do away with the other tether, the power cord.
My notion is that upgrading software for these devices should be made as simple as possible. The proposed solution is speculative, but I believe it merits further discussion.
The Current Situation
When you buy one of these products today, you think you are buying a device. Actually, there is a basic shell of a device, but all the good stuff is in the software. Any software person knows when he turns on his cell phone, for example, that he has to wait for it to "boot up." And that numeric keypad you use to dial phone numbers is also the keyboard you use to program the software.
Effectively, this device consists of three parts. There is the "hardware," there is the embedded "software," and there are the batteries, without which, I hasten to add, nothing will work. Today, this device is packaged as two parts: "the phone," which contains both the hardware and software, and "the batteries." That is just the way things have evolved.
Now this poses an interesting dilemma.
All the intelligence is in the software. So when you want to upgrade the phone, you have two options: 1) somehow upgrade the software, which, today, means either replacing or reprogramming the chip in the phone; or 2) depending on the economics, replace the whole phone with a new one, which, in turn, might be exactly the same shell with a newer version of the chip.
Other devices take a slightly different tack: You can hook them up to your PC, get on the vendor's Web site, and download a new version of the software. Sometimes called an "oil change," this operation allows you to replace the software with a more recent version. The oil change analogy is a little dangerous for some people because it implies that your software gets replaced for you automatically at regular intervals without revealing what internal changes the vendor made, and they find that notion scary. For others, the whole process of using the PC to accomplish the objective seems more akin to changing out an engine instead of just the oil in it. That is, they do not view it as a simple task.
The Software Upgrade Game
Software vendors are under continual pressure to make their products better. This means that they issue, at fairly regular intervals, upgrades to their software. New purchasers get the latest and greatest when they buy. And, to spread the development costs and keep existing customers happy, vendors would like to encourage current users to acquire the latest version too, albeit at a modest price point.
So, how do they get people to upgrade their software?
The industry is wrestling with this issue as we speak. People tend to
get used to their software, and getting them to upgrade to the latest
and greatest version is a bit of a problem. You have to convince them
to pry open their wallets and spend some of their discretionary income
to replace something that already works pretty well. Vendors have tried
various mechanisms, most of them based on a subscription model; TiVo's
"oil change" and AOL's online upgrades, for example, both depend on users
paying for their software (and, implicitly, the upgrades) as part of a
monthly service.
It has been noted in some parts that Microsoft has been tinkering with all sorts of pricing ideas, including subscriptions, to guarantee a steady revenue stream into the foreseeable future.
But once we get past the economic problem, we still have the quasi-technical problem. How do we make the upgrade as easy and user-friendly as possible?
A Modest Proposal
What we ought to do, for cell phones and, by extension, all devices with embedded software, is to package the software with the battery, not with the device. You would buy the basic device without batteries or software, although it wouldn't be worth much -- not even as a doorstop, since it's so lightweight. But at least it could be commoditized down to the lowest unit cost manufacturing efficiencies will allow.
Then, to power it up, you would buy batteries.
1
(Each device would have its own type of battery.) The software would come along, piggybacked onto the battery. We abstract the technical implementation details here; think of it as a "battery pack" if you like; I prefer, for marketing reasons, just to think of it as a "smarter" battery.
This would cause a vast diversification in the battery business, but we have seen industrial transformations of this type before. Today, we tend to think of batteries as a commodity. Actually, they already exist in many sizes and varieties, depending on electrical requirements and how much you want to spend; rechargeable costs more, for instance. You might think that turning such a commodity business into a more variegated "marketplace" is counterintuitive. But not really; as an analog, just think of the infinite variety of tires (car, truck, tractor, snow, racing, high-performance, etc., not to mention a dizzying array of sizes and form factors) that are currently stocked for mass consumption today. Yet most people think of tires as a commodity. And a hundred years ago, they were.
Needless to say, the battery distribution business would change; there would still be the "dumb batteries" we have today, along with the "smart batteries" that would have piggybacked software. Not all corner grocery stores, souvenir shops, and convenience stores would carry both kinds. We would expect though, that over time, more and more stores would stock and carry smart batteries as the demand for them increased.
This transformation would lend another layer of meaning to the phrase "power it up." When you turned on a device, you'd be feeding it electrical power by virtue of the battery; you'd also be giving it intellectual power by virtue of the software on the battery. Power to the hardware, in both senses!
Software Upgrades, Revisited
Under this new regime, when you purchased your software with your batteries, you would upgrade as you go. When your batteries ran out, you would replace them. And when you did, you would get the latest version of the software applicable to your device.
Notice that this has an interesting property: It couples the shelf life of the battery to the useful life of the software, so we wouldn't have to worry about obsolete versions of software lying around.
What about the cost of the upgrade, or, more generically, the cost of the software? No one in his right mind thinks that the batteries for his cell phone should be free. So your batteries would cost a little more, of course, because you'd have to cover the software development expenses. But those expenses would be spread over the cost of all the batteries the software is piggybacked onto.
There is also this wonderful coincidence. Someone who used his device sparingly would replace batteries infrequently. However, whenever he did, he would automatically get upgraded to a recent version of his software. On the other hand, someone who used his device constantly would go through a lot of batteries and would therefore typically be replacing his software with identical copies of what he had been using. The intensive user would see little or no change over time, and the infrequent user would see "step" changes in his software when he swapped out his batteries, something he would do rarely. So there would be a really good match between upgrades and the respective usage patterns.
As the software that goes onto the battery would have to be completely self-contained, we would do away forever with the notion of patching old software. You would throw away your old software with your dead battery, and your fresh battery would start over again. Manufacturers would have to be clever to ensure that features wouldn't change abruptly. At the worst, there might have to be some "release notes" for your new batteries. I think marketing folks could put the appropriate spin on this and turn it into an attractive feature.
The big advantage of this model is that it saves users from having to download software upgrades from the Net. Which is easier -- doing a download and install of software from the Net, or just changing the batteries? Ask your mom.
Some Nice Things Come for Free
We already have this notion that devices with embedded software should be easy to use. As the old saying goes, "There is no Maytag User's Group, because there doesn't have to be." So people think we should adopt an "appliance" model for these devices.
2
Unfortunately, software sometimes gets in the way of this.
But consider some of the benefits of packaging batteries and software together. Want to install your software? Plug in the "softerry."
3
This would bring new meaning to the term "plug and play." Want to move your software from one device to another (compatible) device? Just move your softerry from one device to the other. If the devices weren't compatible, then you would have the equivalent of trying to use the wrong battery. Most people would understand that.
Note that for this scheme to work, the softerry would have to contain some kind of writeable memory in order to store user-specific information (settings, files, etc.). Otherwise it wouldn't be too useful to plug the softerry into another device. The memory could be PROM or NVRAM, but since it would be integrated with the battery, it could even be normal RAM. One reason you might want to upgrade the softerry would be to get more memory.
Our European friends have already started down this path. My friend and colleague Pascal Leroy writes from France: "The GSM phone system in Europe relies on a chip called the SIMS card, which contains (1) information about your rights, subscription, phone number, and so on, and (2) your settings. People have gotten used to plugging their SIMS card into just about any phone to place a call: I was on the train the other day next to two girls, one of whom had a cell phone with an dead battery; she just borrowed her friend's phone, plugged in her own SIMS card, and was able to chat on the phone for the entire trip. And they didn't exactly look like nerds, so this kind of technology is probably usable by just about anybody." This "ease of use" example demonstrates some of potential benefits of the softerry, which would take the idea one step further.
Do you have multiple devices, each of which needs the same software? Well, in the old days, software manufacturers might have worried about you. In many cases it was rather easy, although illegal, to purchase a licensed copy of the software and install it on multiple machines. With the softerry, the question would become moot for both you and the manufacturer. You could either buy multiple softerries to use simultaneously, or you could put a softerry into the device you wanted to use right away, and then transfer it to another device later if you wished. As with ordinary batteries, it would be your choice: cost versus convenience. Here we see the instantiation of the ideal model that maps one copy of the software to one physical device. By making these softerries simple and cheap enough, we would reduce the incentive to copy software illegally.
Why This Will Work
Economics.
People don't like subscriptions. They don't like to be locked into recurring charges. As the economy tightens, we see people cut back, and the first thing they cut back on, if they are smart, are those silent monthly charges. If software vendors decide to go in the direction of subscription pricing, my guess is that they will prosper in good times and get pinched in hard times. I think this is basic economics and psychology at work.
The fundamental dynamic here is that people will always fear that they will not get enough for their money with a subscription. That is, they will always be concerned that their usage will be below average, and hence that they are funding (subsidizing) other "free riders" who use the service more, at their implicit expense.
On the other hand, people are used to paying for batteries. Batteries are a consumable, and you pay for them according to how much energy you use. Use the device more, deplete your batteries more. No one complains about that. To most people, that seems fair.
To illustrate my point, look at the consumption of ink-jet cartridges in low-cost color printers. These cartridges are relatively expensive, but the market tolerates this because they are viewed as a consumable. In fact, there are all sorts of after-market vendors whose existence attests to this basic usage model; their only function is to lower the unit cost.
So by putting the software into the batteries, you would transform it into a consumable that gets thrown away with the dead battery. You would factor the software cost into the price of the battery. Spread over many, many units, the added cost would be pretty low. Coupling software usage to battery usage might ultimately be the simplest algorithm we could ever devise for charging (no pun intended) for software based on a usage model.
Will people (electrically) recharge their software batteries? They could, assuming we have piggybacked our software onto rechargeable batteries. In this case, they would retain their old software, perhaps indefinitely. But it wouldn't invalidate the basic model. And someone could always upgrade their software, if they wanted to, by throwing away a perfectly "good" battery and replacing it with a newer one. Who knows, there might spring up a secondary market for "old" batteries that still hold a charge. Maybe there will be battery exchanges. We could ring up a lot of changes on the basic model. The important concept here is that the free market and its economics would drive things appropriately.
Refinement
There are a few additional details to consider, which might appeal to some of you techno-junkies. By coupling software and batteries, some new horizons open up.
One refinement, suggested by Philippe Kruchten, would be to take advantage of large memory capacities to store the software for multiple devices on a single softerry. This would ease the distribution problem somewhat, as one physical unit could then serve several different devices. So you might imagine a generic "cell phone" battery, and so on. What this would mean is that you could replace your Motorola cell phone with a Nokia cell phone, plug in the softerry you used with the Motorola, and everything would still work. Of course this would require that the various cell phone manufacturers agree on some standards, and that is always tricky.
Conversely, one could imagine a vertically integrated company putting the software for several different device types on one softerry. Then one could purchase, for example, an Ericsson softerry, which would power (both from an electrical and software point of view) devices of different types made by Ericsson.
Today you can, of course, introduce all sorts of power-saving algorithms in the software to economize as much as possible on battery usage. We already do this in laptops, whose software ships with the device. Under our proposal, we would put these same power-saving algorithms where they more logically should reside: into the laptop battery.
Also, consider a generation "n" battery with generation "n" software. Let's say that in the next revision of the software, you improve your algorithms and so on, so that you can get the same amount of work done in the same amount of time with less electrical power. That means you can now ship generation "n+1" software on a battery that has less electrical output and still achieve the same result. So the price of the battery could come down, or your profit could go up, or some combination of both.
These possibilities are all definitely within the realm of current technology but not essential. They are refinements of the original idea, and I want to obey the KISS
4
principle as much as possible.
What About Software Piracy?
Fundamentally, we want to eliminate piracy by making the softerry the most persuasive economic choice for the majority of users. As with all other schemes, when we try to build a better technical mousetrap, we just incite smarter mice. Better to figure out a way to make them buy the cheese of their own accord. Perhaps the softerry's memory will be programmed at the factory, using a device that is relatively expensive and not generally available to the public. Then it would be cheaper just to buy a new softerry instead of copying the software from an existing one and trying to "reburn" it onto an older softerry. But, fundamentally, we are not trying to address software piracy with this proposal. It may have some fortuitous side effects, but that is incidental.
Until the Sun Takes Over
Today lots of money is spent making batteries better (smaller, more powerful, longer lasting, etc.) so that we can become mobile. Some day, there might be solar-recharged capacitors capable of replacing batteries entirely. This technology depends on getting the form factor small enough, the capacitance large enough, and the solar panel interface nearly perfect. We would use the capacitor as a "virtual battery." It would be just another way of storing energy for use at a later time. However, unlike batteries, the capacitor/solar panel combination would not have to be replaced periodically. Until that day comes, we will be replacing or recharging batteries. So why not marry them to our software?
It would be foolhardy of me to claim that I have stumbled upon the next great vertical integration of our time: batteries and software. On the other hand, the idea intrigues me. I doubt very strongly that Rational will be getting into the softerry business anytime soon; that is why we have a Franklin's Kite column, after all. It lets us explore the pluses and minuses of such schemes, without any terminal effects.
Softerries would solve the software upgrade problem for electronic devices by making the operation as simple as changing batteries. They would alter the pricing dynamics, by making software more of a consumable than a capital item. As the devices that the embedded software reside in are themselves becoming commodities, this makes sense. There may ultimately be interesting distribution issues for softerries, but I'm confident that these could be addressed effectively.
Notes
1
Of course, these batteries may be packaged with the device at the time you buy it.
2
We acknowledge that a Maytag washing machine is not a handheld device.
3
Sounds better than "batware," which might be misconstrued as a Batmobile accessory.
4
KISS stands for Keep It Simple, Stupid!
About the author | 
| | Recently appointed CEO of Ravenflow, an Emeryville, California-based company delivering precision requirements validation for software developers, Joe Marasco served as senior vice president and business unit manager for Rational Software prior to the company's acquisition by IBM. He held numerous positions of responsibility in marketing, development, and the field sales organization, overseeing initiatives for Apex and Visual Modeler for Microsoft Visual Studio. After retiring from Rational in 2003, he published The Software Development Edge, a collection of his essays on software project management originally published in The Rational Edge. He holds a Ph.D. in physics from the University of Geneva, Switzerland, and an M.B.A. from the University of California, Irvine. |
Rate this page
| |
