Google search is broken, and we all suffer

Google has a problem. That problem is web search.

Google, the long-time leader in web search, recently modified its techniques to use artificial intelligence (AI). The attempt at AI-driven search has lead to embarrassing results. One person asked how to keep cheese on pizza, and Google suggested using glue. Another asked about cooking spaghetti, and Google recommended gasoline.

The problem was that Google pointed its AI search engine at the entire web, absorbing posts from various sources. Some of those posts contained text that was a joke or sarcastic. A human would be able to tell that the entries were not to be used in search results, but Google's algorithm isn't human.

Google has rediscovered the principle of "garbage into a computer system yields garbage output".

One might think that Google could simply "pull the plug" on the AI search and revert back to the older mechanisms it used in the past. But here too Google has a problem: the old search algorithms don't work (anymore).

Google started with a simple algorithm for search: count links pointing to the page. This was a major leap forward in search; previous attempts were curated by hand. Over the years, web designers have "gamed" the Google web crawler to move their web pages up in the results, and Google has countered with changes to their algorithm. The battle continues; there are companies that help with "Search Engine Optimization" or "SEO". Those optimizing companies have gotten quite good at tweaking web sites to appear high in searche results. But the battle is lost. Despite Google's size (and clever employees) the SEO companies have won, and the old-style Google search no longer shows meaningful results but mostly advertisement links.

SEO has changed Google search from a generic search engine into a sales lead tool. If you want to purchase something, Google is a great way to find a good price. But if you want something else, Google is much less useful that it used to be. It is no longer a tool for answers to general questions.

That means that search, for the internet, is broken.

It's not completely broken. In fact,"broken" is too strong of a word for the concept. Better choices might be "damaged" or "compromised", or even "inconsistent". Some searches work, and others don't.

Broken, damaged, or inconsistent, Google's search engine has suffered. Its reputation is reduced, and fewer people use it. That's a problem for Google, because the search results is a location to display advertisements, and advertisements are Google's major source of income.

A broken Google search is a problem for us all, in two ways.

First, with Google search broken, we (all) must now find alternative means of answering questions. AI might help for some -- although I don't recommend it for recipes -- and that can be a partial replacement. Other search engines (Bing, Yahoo) may work for now, but I expect that they will succumb to the same SEO forces that broke Google. With no single reliable source of information, we must now turn to multiple sources (stackexchange, Red Hat web pages, and maybe the local library) which means more work for us.

Secondly, the defeat of the Google whale to the SEO piranhas is another example of "this is why we cannot have nice things". It is the tragedy of the commons, with individuals acting selfishly and destroying a useful resource. Future generations will look back, possibly in envy, at the golden age of Google and a single source of reliable information.

Google raises prices, which may be a good thing

Google has raised prices for several of its services. The annual rates for Workspace, YouTube Premium, and Nest are all going up. The internet is not happy, of course. Yet I see a benefit in these price increases, and not just to Google. I think consumers may benefit from them.

It does sound odd. How can consumers -- who pay these prices -- benefit from increases? Wouldn't they benefit more from decreases in prices?

My answer is: not necessarily.

My thinking is this:

While Google is a large company, with many products and services, most of its revenue comes from advertising.  One could say that Google is an advertising company that has a few side projects that are supported by advertising revenue.

The model was: make a lot of money in advertising and offer other services.

Google was -- and is -- wealthy enough that it could give away e-mail and storage. When Google first offered it's GMail service, it allowed up to one Gigabyte of storage to each user, an amount that was unheard-of at the time.

It's tempting to want this model to continue. It gives us "something for nothing". But letting advertising pay for everything else has a downside.

When a service depends on revenue from advertising, it is natural for the company to expect that service to help advertising. If the service doesn't, then that service is either changed or discontinued. (Why continue to offer a service that costs money to maintain but doesn't help with revenue?)

Google has a reputation for cancelling projects. Perhaps those projects were cancelled because they did not provide revenue via advertising -- or didn't help the advertising group gain customers, or better market data, or something else.

When a service is funded by advertising, that service is beholden to advertising.

In contrast, when a service has its own revenue -- enough revenue to generate a profit -- then that service is somewhat isolated from the advertising budget. If YouTube Premium costs $X to run and brings in $Y in revenue (and Y is greater than X) then YouTube Premium has a good argument to continue, despite what the folks in advertising want.

The same goes for other services like Nest and Google's cloud storage.

I expect that no one enjoys increasing prices. I certainly don't. But I recognize the need for services to be independent, and free of the influence of other lines of business. Higher revenue leads to services that are stronger and longer-lasting. (Or so I like to think.)

I may grumble about the increase in prices for services. But I grumble with restraint.

Everyone who is not Apple

Apple has direct control over the design of their hardware and software, a situation that has not been seen in the history of personal computers. I expect that they will enjoy success -- at least for a while -- with new, powerful designs.

But what about everyone else? What about Microsoft, the maker of Windows, Office, Azure services, Surface tablets and laptops, and other things? What about Dell and Lenovo and Toshiba and HP, the makers of personal computers? What Google, the maker of Chromebooks and cloud services?

That's a big question, and it has a number of answers.

Microsoft has a number of paths forward, and will probably pursue several of them. For its Surface devices, it can design systems on a chip that correspond to Apple's M1 chips. Microsoft could use ARM CPUs; it has already ported Windows to ARM and offers the "Surface X" with ARM. Microsoft could design a system-on-a-chip that uses Intel CPUs; such would provide binary compatibility with current Windows applications. Intel chips generate more heat, but Microsoft has success with Intel chips in most of its Surface line, so a system-on-a-chip with Intel could be possible. These paths mirror the path that Apple has taken.

Microsoft, unlike Apple, has another possible way forward: cloud services. Microsoft could design efficient processors for the computers that run data centers, the computers that host virtual instances of Windows and Linux. Such a move would ease the shift of processing from laptops and desktop computers and the cloud. (Such a shift is possible today; system-on-chip designs make it more efficient.) Microsoft may work with Intel, or AMD, or even IBM to design and build efficient hardware for cloud data centers.

Manufacturers of personal computers may design their own system-on-chip answers to the M1 processor. Or they may form a consortium and design a common chip that can be used by all (still allowing for custom system-on-chip designs and the current discrete component designs). Microsoft has, for a long time, provided a reference document for the requirements of Windows, and system-on-chip designs would follow that set of requirements just as laptops and desktops today follow those requirements.

PC manufacturers do lose some control when they adopt a common design. A common design would be common, and available to all manufacturers. It prevents a manufacturer from enhancing the design by selecting better components. Rather than shift their entire product line to system-on-chip design, manufacturers will probably use the system-on-chip design for only some of the offerings, keeping some products with discrete designs (and enhancements to distinguish them from the competition).

Google does not have to follow the requirements for Windows; it has its own requirements for Chromebooks. System-on-chip design is a good fit for Chromebooks, which already use both Intel and ARM chips (and few users can see the difference). The performance improvement of system-on-chip design fits in nicely with Google's plan for games on Chromebooks. The increase in power allows for an increase in the sophistication of web-based apps.

I am willing to wait for Microsoft's response and for Google's response. I think we will see innovative designs and improvements to the computing experience. I expect Microsoft to push in two directions: system-on-chip designs for their Surface tablets, and cloud-based applications running on enhanced hardware. Google will follow a similar strategy, enhancing cloud hardware and improving the capabilities of Chromebooks.

Google replaces Google Pay with Google Pay to make customers pay

Google caused a stir this week when it announced a complete re-vamp of its Google Pay service. The old Google Pay was web-based and allowed for free payments by using debit accounts (the ACH network). The new Google Pay is SMS-based and imposes fees on all transactions including debit accounts. (And since it is built on top of SMS, the new Google pay works only on cell phones. It does not work on desktops, laptops, or wifi-only tablets.)

To make matters more confusing, the old service was named "Google Pay". The new service is also named "Google Pay".

Reaction has been sharp. The discussions thus far run along the lines of "Google kills another usable service" to "this change brings no benefit to the customer". Both ideas are correct, but no one has asked why Google would make such a change.

So why would Google make such a change?

A few reasons come to mind.

First, an SMS-based payment system works well in India, which is a large market for Google. A payment system in India, especially one in which every transaction provides income to Google, would help Google's bottom line.

That doesn't explain why Google would eliminate a working payment system in the US and force its current customers to change to the new Google Pay. The change requires not only installing the new app but also re-registering (with a phone number) and rebuilding contact lists.

I think that more is going on than an evil plan to make users dance through hoops. Which brings me to my second idea.

I think Google, internally, is reviewing its offerings and looking at ways to increase profits. It may be that Google (or Alphabet, it's not clear who is calling the shots here) is looking to grow revenues. Google is doing this by either reducing or eliminating its free services, replacing them with paid-for services.

Google started as a search engine, but wowed the world with its e-mail system. It offered free e-mail with extra large storage (1GB per account) at a time when most companies charged for e-mail and limited storage to hundreds of Kilobytes, perhaps a Megabyte or two. The few free e-mail services offered even less storage.

After e-mail, Google offered many other services, most of them free. But over time, the free services are becoming... not free. Services that were free for individuals had costs for organizations. Of course, the accounts for organizations had extra features that individual users never needed, such as administrative functions and group permissions. It was easy to justify the fees.

Google charging more fees is, I think, the way of the future. Google has a large user base, and is most likely counting on people staying with Google, paying relatively small fees. If some customers leave, Google will probably not miss them.

It may be that paying for services is the way of the future. It may shock some users, and there may be much shouting and gnashing of teeth, but it is a definite possibility.

What interests me is the notion that Google is doing this not because they want to, and not because they can, but because the have to. Is it possible that advertising revenue (Google's current source of income) is no longer sufficient to power Google?

The future of Firefox

Use of Mozilla's Firefox browser is declining (at least as a percentage of market share), and people are concerned.

Some are concerned that we will lose an option in the browser market. Others are concerned that the demise of Firefox signals a forthcoming decline of open-source software. Mozilla, of course, is concerned about its business.

I'm not sure what Mozilla should do in this situation. I do have some observations:

First, people select browsers (and other things) for one of two reasons.

1) They want to use the specific product (in this case, the Firefox browser)

2) They don't want to use the alternatives (in this case, Internet Explorer, Edge, Chrome, Safari, etc.)

To improve its market share, Mozilla will have to either provide a product or service that people want to use, or be an alternative to a product that people don't want to use. Mozilla must either make a better browser, one that people look at and think to themselves "yeah!", or wait for people to dislike the other browsers on the market.

When Chrome appeared on the market, people used it, I think, for the latter reason. At the time, Internet Explorer (IE) was the most commonly used browser (sometimes by corporate dictat) and people did not like it. Chrome was not Internet Explorer, and by using Chrome, one could "poke Microsoft in the eye".

But that was then. Now, people use Chrome because they want to. People might have chosen Chrome after using Gmail, and may have had favorable opinions of Google due to the 1GB space for mailboxes, which was quite large at the time. And Gmail was free!

Whatever the reasons, people like Chrome. Mozilla does not have the tailwind of people disliking their current browser.

Waiting for potential customers to dislike their current product is not a viable strategy. People may be unhappy with some of Google's practices, and that may drive some away from Chrome (and some of those to Firefox) and Mozilla has been advertising along those lines.

But dislike of Google is probably not enough. Mozilla needs "a better mousetrap".

And I'm not sure how they can build one.

Three models of computing

Computing comes in different flavors. We're probably most familiar with personal computers and web applications. Let's look at the models used by different vendors.

Apple has the simplest model: Devices that compute. Apple has built it's empire on high-quality personal computing devices. They do not offer cloud computing services. (They do offer their "iCloud" backup service, which is an accessory to the central computing of the iMac or Macbook.) I have argued that this model is the same as personal computing in the 1970s.

Google has a different model: web-based computing. This is obvious in their Chromebook, which is a lightweight computer that can run a browser -- and nothing else. All of the "real" computing occurs on the servers in Google's data center. The same approach is visible in most of the Google Android apps -- lightweight apps that communicate with servers. In some ways, this model is an update of the 1970s minicomputer model, with terminals connected to a central processor.

Microsoft has a third model, a hybrid of the two. In Microsoft's model, some computing occurs on the personal computer and some occurs in the data center. It is the most interesting of the two, requiring communication and coordination of two components.

Microsoft did not always have their current approach. Their original model was the same as Apple's: personal computers as complete and independent computing entities. Microsoft started with implementations of the BASIC language, and then sold PC-DOS to IBM. Even early versions of Windows were for stand-alone, independent PCs.

Change to that model started with Windows for Workgroups, and became serious with Windows NT, domains, and ActiveDirectory. Those three components allowed for networked computing and distributed processing. (There were network solutions from other vendors, but the Microsoft set was a change in Microsoft's strategy.)

Today, Microsoft offers an array of services under its "Azure" mark. Azure provides servers, message queues, databases, and other services, all hosted in its cloud environment. They allow individuals and companies to create applications that can combine PC and cloud technologies. These applications perform some computing on the local PC and some computing in the Azure cloud. You can, of course, build an application that runs completely on the PC, or completely in the cloud. That you can build those applications shows the flexibility of the Microsoft platform.

I think this hybrid model, combining local computing and server-based computing, has the best potential. It is more complex, but it can handle a wider variety of applications than either the PC-only solution (Apple's) or the server-only solution (Google's). Look for Microsoft to support this model with development tools, operating systems, and communication protocols and libraries.

Looking forward, I can see Microsoft working on a "fluid" model of computing, where some processing can move from the server to the local PC (for systems with powerful local PCs) and from the PC to the server (for systems with limited PCs).

Many things in the IT realm started in a "fixed" configuration, and over time have become more flexible. I think processing is about to join them.

For the future of Java, look to Google

What is the future of Java? It is a popular language, perhaps a bit long in the tooth, yet still capable. It struggled under Sun. Now it is the property of Oracle.

Oracle is an interesting company, with a number of challenges. Its biggest challenge is the new database technologies that provide alternatives to SQL. Oracle built its fortune on the classic, ACID-based, SQL database, competing with IBM and Microsoft.

Now facing competition not only in the form of other companies but in new technologies, Oracle must perform. How will is use Java?

For the future of Java, I suggest that we look to Google and Android. Java is part of Android -- or at least the Java bytecode. Android apps are written in Java on standard PCs, compiled into Java bytecode, and then delivered to Android devices. The Android devices (phones, tablets, what-have-you) use not the standard JVM interpreter but a custom-made one named "Dalvik".

Oracle and Google have their differences. Oracle sued Google, successfully, for using the Java APIs. (A decision with which I disagree, but that is immaterial.)

Google now faces a decision: stay with Java or move to something else. Staying with Java will most likely paying Oracle a licensing fee. (Given Oracle's business practices, probably an exorbitant licensing fee.)

Moving to a different platform is equally expensive. Google will have to select a new language and make tools for developers. They will also have to assist developers with existing applications, allowing them to migrate to the new platform.

Exactly which platform Google picks isn't critical. Possibly Python; Google supports it in their App Engine. Another candidate is Google Go, which Google also supports in App Engine. (The latter would be a little more complicated, as Go compiles to executables and not bytecode, and I'm not sure that all Android devices have the same processor.)

Google's decision affects more that just Google and Android. It affects the entire market for Java. The two big segments for Java are server applications and Android applications. (Java as a teaching language is probably the third.) If Google were to move Android to another language, a full third of the Java market would disappear.

If you have a large investment in Java applications (or are considering building new Java applications), you may want to keep an eye on Google and Android.

Google, Oracle, and Java

Apple has a cozy walled garden for its technology: Apple devices running Apple operating systems and Apple-approved apps written in Apple-controlled languages (Objective-C and now Swift).

Microsoft is building a walled garden for its technology. Commodity devices with standards set by Microsoft, running Microsoft operating systems and apps written in Microsoft-controlled languages (C#, F#, and possibly VB.NET). Microsoft does not have the same level of control over applications as Apple; desktop PCs allow anyone with administrator privileges to install any app from any source.

Google has a walled garden for its technology (Android), but its control is less than that of Apple or Microsoft. Android runs on commodity hardware, with standards set by Google. Almost anyone can install apps on their Google phone or tablet. And interestingly, the Android platform apps run in Java, a language controlled by... Oracle.

This last aspect must be worrying to Google. Oracle and Google have a less than chummy relationship, with lawsuits about the Java API. Basing a walled garden on someone else's technology is risky.

What to do? If I were Google, I would consider changing the language for the Android platform. That's not a small task, but the benefits may outweigh the costs. Certainly their current apps would have to be re-written for the New language. A run-time engine would have to be included in Android. The biggest task would be convincing the third-party developers to change their development process and their existing apps. (Some apps may never be converted.)

Which language to pick? That's an easy call. It should be a language that Google controls: Dart or Go. Dart is designed as a replacement for JavaScript, yet could be used for general applications. Go is, in my opinion, the better choice. It *is* designed for general applications, and includes support for concurrency.

A third candidate is Python. Google supports Python in their App Engine cloud platform, so they have some familiarity with it. No one company controls it (Java was controlled by Sun prior to Oracle) so it is unlikely to be purchased.

Java was a good choice for launching the Android platform. I think the languages Go and Python are better choices for Android now.

Let's see what Google thinks.

With no clear IT leader, expect lots of changes

The introduction of the IBM PC was market-wrenching. Overnight, the small, rough-and-tumble market of microcomputers with diverse designs from various small vendors became large and centered around the PC standard.

From 1981 to 1987, IBM was the technology leader. IBM lead in sales and also defined the computing platform.

IBM's leadership fell to Compaq in 1987, when IBM introduced the PS/2 line with its new (incompatible) hardware. Compaq delivered old-style PCs with a faster buss (the EISA buss) and notably the Intel 80386 processor. (IBM stayed with the older 80286 and 8086 processors, eventually consenting to provide 80386-based PS/2 units.) Compaq even worked with Microsoft to deliver newer versions of MS-DOS that recognized larger memory capacity and optical disc readers.

But Compaq did not remain the leader. It's leadership declined gradually, to the clone makers and especially Dell, HP, and Gateway.

The mantle of leadership moved from a PC manufacturer to the Microsoft-Intel duopoly. The popularity of Windows, along with marketing skill and software development prowess led to a stable configuration for Microsoft and Intel. Together, they out-competed IBM's OS/2, Motorola's 68000 processor, DEC's Alpha processor, and Apple's Macintosh line.

That configuration held for two decades, roughly from 1990 to 2010, when Apple introduced the iPhone. The genius move was not the iPhone hardware, but the App Store and iTunes, which let one easily find and install apps on your phone (and pay for them).

Now Microsoft and Apple have the same problem: after years of competing in a well-defined market (the corporate PC market) they struggle to move into the world of mobile computing. Microsoft's attempts at mobile devices (Zune, Kin, Surface RT) have flopped. Intel is desperately attempting to design and build processors that are suitable for low-power devices.

I don't expect either Microsoft or Intel to disappear. (At least not for several years, possibly decades.) The PC market is strong, and Intel can sell a lot of its traditional (heat radiator that happen to compute data) processors. Microsoft is a competent player in the cloud arena with its Azure services.

But I will make an observation: for the first time in the PC era, we find that there is no clear leader for technology. The last time we were leaderless was prior to the IBM PC, in the "microcomputer era" of Radio Shack TRS-80 and Apple II computers. Back then, the market was fractured and tribal. Hardware ruled, and your choice of hardware defined your tribe. Apple owners were in the Apple tribe, using Apple-specific software and exchanging data on Apple-specific floppy disks. Radio Shack owners were in the Radio Shack tribe, using software specific to the TRS-80 computers and exchanging data on TRS-80 diskettes. Exchanging data between tribes was one of the advanced arts, and changing tribes was extremely difficult.

There were some efforts to unify computing: CP/M was the most significant. Built by Digital Research (a software company with no interest in hardware), CP/M ran on many different configurations. Yet even that effort could not span the differences in processors, memory layout, and video configurations.

Today we see tribes forming around multiple architectures. For cloud computing, we have Amazon.com's AWS, Microsoft's Azure, Google's App Engine. With virtualization we see VMware, Oracle's VirtualBox, the aforementioned cloud providers, and newcomer Docker as a rough analog of CP/M. Mobile computing sees Apple's iOS, Google's Android, and Microsoft's Windows RT as a (very) distant third.

With no clear leader and no clear standard, I expect each vendor to enhance their offerings and also attempt to lock in customers with proprietary features. In the mobile space, Apple's Swift and Microsoft's C# are both proprietary languages. Google's choice of Java puts them (possibly) at odds with Oracle -- although Oracle seems to be focussed on databases, servers, and cloud offerings, so there is no direct conflict. Things are a bit more collegial in the cloud space, with vendors supporting OpenStack and Docker. But I still expect proprietary enhancements, perhaps in the form of add-ons.

All of this means that the technology world is headed for change. Not just change from desktop PC to mobile/cloud, but changes in mobile/cloud. The competition from vendors will lead to enhancements and changes, possibly significant changes, in cloud computing and mobile platforms. The mobile/cloud platform will be a moving target, with revisions as each vendor attempts to out-do the others.

Those changes mean risk. As platforms change, applications and systems may break or fail in unexpected ways. New features may offer better ways of addressing problems and the temptation to use those new features will be great. Yet re-designing a system to take advantage of new infrastructure features may mean that other work -- such as new business features -- waits for resources.

One cannot ignore mobile/cloud computing. (Well, I suppose one can, but that is probably foolish.) But one cannot, with today's market, depend on a stable platform with slow, predictable changes like we had with Microsoft Windows.

With such an environment, what should one do?

My recommendations:

Build systems of small components  This is the Unix mindset, with small tools to perform specific tasks. Avoid large, monolithic systems.

Use standard interfaces  Use web services (either SOAP or REST) to connect components into larger systems. Use JSON and Unicode to exchange data, not proprietary formats.

Hedge your bets  Gain experience in at least two cloud platforms and two mobile platforms. Resist the temptation of "corporate standards". Standards are good with a predictable technology base. The current base is not predictable, and placing your eggs in one vendor's basket is risky.

Change your position  After a period of use, examine your systems, your tools, and your talent. Change vendors -- not for everything, but for small components. (You did build your system from small, connected components, right?) Migrate some components to another vendor; learn the process and the difficulties. You'll want to know them when you are forced to move to a different vendor.

Many folks involved in IT have been living in the "golden age" of a stable PC platform. They may have weathered the change from desktop to web -- which saw a brief period of uncertainty. More than likely, they think that the stable world is the norm. All that is fine -- except we're not in the normal world with mobile/cloud. Be prepared for change.

File Save No More

The new world of mobile/cloud is breaking many conventions of computer applications.

Take, for example, the long-established command to save a file. In Windows, this has been the menu option File / Save, or the keyboard shortcut CTRL-S.

Android apps do not have this sequence. In fact, they have no sequence to save data. Instead, they save your data as you enter it, or when you dismiss a dialog.

Not only Android apps (and I suspect iOS apps), but Google web apps exhibit this behavior too. Use Google Drive to create a document or a spreadsheet.

Breaking the "save file" concept allows for big changes. It lets us get rid of an operation. It lets us get rid of menus.

It also lets us get rid of the concept of a file. We don't need files in the cloud; we need data. This data can be stored in files (transparently to us), or in a database (also transparently to us), or in a NoSQL database (also transparently to us).

We don't care where the data is stored, or which container (filesystem or database) is used.

We do care about getting the data back.

I suspect that we will soon care about previous versions of our data.

Windows has add-ins for retrieving older versions of data. I have used a few, and they tend to be "hacks": things bolted on to Windows and clumsy to use. They don't save every version; instead, they keep snapshots at scheduled times.

Look for real version management in the cloud. Google, with its gigabytes of storage for each e-mail user, will be able to keep older versions of files. (Perhaps they are already doing it.)

The "File / Save" command will be replaced with the "File Versions" list, letting us retrieve an old version of the file. The list will show each and every revision of the file, not just the versions captured at scheduled times.


Once a major player offers this feature, other players will have to follow.

Microsoft was nicer than Google

Google recently announced that they will be terminating their "Google Reader" service. The announcement drew a fair amount of attention.

The termination of Google Reader shows us that Microsoft was much better than Google. The reaction from "the rest of us" shows us that we have certain expectations of software vendors.

Really.

Let's start with Microsoft.

Microsoft has, over the years, offered many products. The list includes operating systems (MS-DOS and Windows), languages (BASIC, Visual Basic, FORTRAN, COBOL, C, C++, C#, F#, and even Pascal), office tools (Word, Multiplan, Excel, Powerpoint, Access, Project), games, databases, and more.

It's an impressive list. What's more impressive is the lifetime of most of those offerings.

Microsoft offered MS-DOS from 1981 until, um, some time in the 1990s when Windows 95 was released. It offered Windows (in one form or another from the mid 1980s until today (and it keeps offering it). Microsoft's BASIC has a longer history than MS-DOS, starting in the late 1970s and continuing to today. These products have been continuously offered to customers.

Now, I recognize that the products changed over time. MS-DOS grew over time, adding features and capabilities. Windows also grew. BASIC had significant changes, especially in its "Visual Basic" stages.

Microsoft may have changed its products, but it (usually) provided a path forward. MS-DOS 2.0 was replaced by MS-DOS 3.1, which in turn was replaced by MS-DOS 3.3. Windows 3.1 was replaced by Windows 95. BASIC was replaced by Visual Basic (and there were several of those), and Visual Basic 6 was replaced by VB.NET.

Some replacements were easy, and some were difficult. But they were there.

Yes, I know that some products were withdrawn with no replacement. The IronPython and IronRuby projects were terminated. The Visual J# compiler has faded into oblivion. There was no successor for Microsoft "Bob". You can add your favorite discontinued product to this list.

All in all, Microsoft has been very good at providing successor products. Perhaps this is because of the revenue that licenses provide. When Microsoft discontinues a product, it wants people to pay for a new product. What better way to keep customers than to offer a new version?

Now let's look at Google.

Google's advertising-driven revenue provides different incentives. Revenue is not generated by users (for most products). Instead, revenue comes from advertising. That advertising revenue powers the development and support of products.

Some Google products are experiments, explorations of markets and possibly technology. (Google's App Engine comes to mind as an exploration of cloud computing.)

If a product is not performing (insufficient advertising revenue), then the logical decision is to replace it with a new platform for advertising. But that new platform does not have to offer anything close to the features of the prior product.

I suspect that the outrage at Google's decision to terminate Reader was caused in part by surprise. We, the users of software, expected Google to act like Microsoft. When they did not, when Google acted in a way that varied from our expectations, we became angry.

Which is ironic, as a lot of us always cheered Google for *not* acting like Microsoft.

Yahoo's opportunity

In all of the news about Apple and Google and Amazon.com and Microsoft, we forget the other players. The one that I am pondering is Yahoo.

Can Yahoo succeed in the new land of mobile/cloud computing?

People like Yahoo's products. It's e-mail and Flickr offerings are capable and reliable. (I use the "pro" versions of both, so I pay a nominal annual fee for them.)

But Yahoo's success has been on the web. Can it move to mobile/cloud?

One challenge for Yahoo will be living in the world of combined (or at least coordinated) hardware and software. Apple, Microsoft, Google, and Amazon.com all sell solutions that encompass hardware and software, and this is re-enforced with the DRM-enabled walled garden for each. Yahoo's products live in the software realm, and Yahoo has no hardware to augment its offerings. (This may be a good thing. The market is crowded with iOS and Android devices, and even Microsoft is having a difficult time getting its Surface tablet into the market.)

Yahoo does partner with Microsoft for search -- Yahoo search is driven by Microsoft's Bing engine. But I think that Yahoo can survive with other areas.

Yahoo's biggest advantage may be its reputation. It doesn't have rabid followers like Apple or Microsoft; instead of fanboys it has what might be best described as a loyal following. Yahoo has been a quiet if not good member of the software world. It has not unsold books to people, or arbitrarily rejected applications, or treated developers poorly.

One person asked of Marissa Mayer: "Please, make Yahoo cool again." I agree. We need a company that makes computing cool. And Yahoo may just be the company that can do it.