standards that define them are more durable. 5 An organization’s standard package choice therefore involves participation in networks that may last a decade or often longer. Shapiro and Varian34 argue that when buying standard technology we should look ahead but reason back, noticing the network and the evolution process that produced it. We applaud and echo this advice that is valid also when selecting packaged software. This principle is useful to include when comparing a proprietary software package from a local vendor with that of a software package built upon an open global standard.

Principle Three:
When choosing packaged software,
there is safety in numbers.

One route to mitigating the perceived risk in purchasing packaged software is to choose a package based on its historical and current success, as measured by the financial success of the software package’s producer and the size of the associated network. Flocking behavior is a low risk strategy that is worth pursuing for software support of non-core functionality and for companies that consider themselves followers. Below, we describe two scenarios representing opposite outcomes of a competition between software packages; namely, blind alleys and one-way streets. 12

The blind alley scenario refers to the
situation where an organization has
adopted a package that is losing its
market share to competing packages.
David12 uses the term “angry orphan”
to describe the situation of the los-
ing package. He points out that such
products often show a sudden rapid
development when they are losing the
battle. For example, the greatest speed
of innovation in sail ships happened as
the steam engine challenged the sail as
the leading propelling technology on
sea voyages. Despite the sudden and
remarkable development, sail boats
never really challenged the inevitable
change to steam engine boats. In a
similar manner, the losing software
package might undergo rapid develop-
ments, but shrinking network effects
make the downward spiral inevitable.
In a special case of the blind alley sce-
nario, the losing package manages to
capture a niche market network where
it may sustain itself for years—or even
perpetually, giving organizations the
choice of staying with the incumbent
producer or giving them time to look
for migration paths toward a standard
package with more perceived vitality. 17

 

Principle four:
focus on compatibility
and beware of false gold.a
Because of the long life expectancy of
organizational data stored in some (of-
ten proprietary) format (see Principle
Two), backward compatibility between
software systems becomes a major fac-
tor when organizations consider new
software investments. Sometimes soft-
ware adheres to one common standard,
enabling user organizations to choose
among competing packages based on
features such as price, performance,
a By false gold or fool’s gold we mean something
that appears attractive but in reality is not valu-
able at all.

usability, etc. Most often, however, compatibility is not a clear binary issue. As standards and packages evolve and producers compete against each other, packages may converge or diverge on some features, such as, reaching or breaking compatibility. 33 Of course, this development can be caused by legitimate technical design and implementation decisions, but it may also be caused by the producer’s perceived advantage in changing the degree of compatibility or interoperability with competing packages.

A producer may differentiate its package from the competition by adding proprietary features and unwarranted proprietary extensions to an open standard. There are some calls for the execution of this predatory business technique of “embrace, extend, and extinguish,” and often Microsoft is associated with an almost flawless execution of the technique. Only the law suits that doubtlessly follow spoil the perfection. One historical example is the fight between Sun and Microsoft over Java and extensions to Java. 32 The practice of adding proprietary extensions to an (open) standard is successful when some adopters find the proprietary features attractive and implement them. However, it is important to be aware that proprietary features that might be useful for the singular adopter are in fact false gold for the network at large. Every time a proprietary feature is implemented it adds to the switching costs, meaning that it will be harder to pull away from the software package that embeds the proprietary extensions. 34 For the network, it means that proprietary features become entrenched as de facto standards, and for the community in general, it becomes an insurmountable barrier to change, thus diminishing the value of a standard.

The break-down of open standards happens in many cases where there is no central governance of a standard by a central institution or authority, and even if such governance does exist, standards often break down anyway as competitors extend the limits of the standard. 9 One example that we claim to be false gold comes from the company Linksys (owned by Cisco) which has extended its wireless network equipment with proprietary protocols, thus doubling the throughput of the non-propri-