When Google launched its Android OS, Apple’s iPhone controlled an overwhelming amount of the smartphone market. Giving Android away as an open source platform made it easier for Google to work together with the other phone manufacturers to create a flourishing platform that could support apps that everyone could use. The open source license made each company an equal partner in the project by giving them access to the source code and control. They could feel secure in choosing it because they knew that Google couldn’t revoke access.
Open-sourcing code to push back against a rival
This shared process is growing more common. OpenStack, a project sponsored by Rackspace, lets smaller cloud companies band together and offer a common platform that will be more attractive than the dominant cloud from Amazon. Not only can the customers choose between multiple companies, they can also install the cloud tools in their own data center. The same basic structure is found in all of the clouds, and the scripts work the same everywhere.
Tapping open source to launch a competitor
The open source license makes one thing simple: Starting up a rival. All it takes to create a new company from scratch is access to the source code repository. After you download it, you can hang your shingle and start competing from the first day – heck, the first few minutes.
Starting up a competitor, though, is far different from sustaining the effort. Downloading the code is easy, but gaining even the basic competence takes months. Becoming a true expert can take years. Really competing means building a team that can offer real expertise.
This is why competition only appears in rapidly burgeoning areas where demand far exceeds supply. When interest in Hadoop exploded several years ago, new startups appeared quickly. All began with the same Hadoop core, but they quickly began to specialize by offering their own special add-ons.
Open-source to keep competition in check
Competition in the world of open source is a two-way street. While anyone can come along and snarf source code in seconds, they are often bound by a license that forces them to contribute all of their innovations back. If the new competitor does anything clever, all of the old teams also gain access to everything. Some of the most popular licenses like the GPL guarantee that everyone must share alike.
This share-and-share-alike rule makes it hard for any upstart to challenge an effective leader. Any neat innovations that come from the upstart can be absorbed by the leader, making it hard for the upstart to gain any real traction. The rule that makes it easy to start up a competitor also makes it impossible for the competition to flourish.
Michael Tiemann, one of the founders of the early open source powerhouse Cygnus, once said presciently, “Fortunately, the open source model comes to the rescue again. Unless and until a competitor can match the 100-plus engineers we have on staff today, most of whom are primary authors or maintainers of the software we support, they cannot displace us from our position as the ‘true GNU’ source. The best they can hope to do is add incremental features that their customers might pay them to add. But because the software is open source, whatever value they add comes back to Cygnus.”
While this can sound like an evil monopolist speaking, the idea has limits. If the leader does a bad job, invests in silly enhancements, or squanders its revenue on worthless add-ons, a new fork can steal the momentum. It’s not impossible.
This rule limiting the power of forks doesn’t hold if there are two legitimate reasons for the separate code bases to exist. If there are two distinct uses for the software, two different groups can easily specialize in both. The competition can survive if it serves a different and distinct market.
Open-source to drive a hard bargain
While many open source licenses are flexible, some are increasingly Draconian. One of the newest, the Affero GPL, insists that the code must be shared if the code is merely running on a public server. The license emerged after some in the open source community noticed that some developers were benefiting from open source software but avoiding the requirement to share their own contributions. They weren’t “distributing” the software, just running it, and the GPL only forced sharing when you “distributed” the software.
Some developers find this requirement easy to follow. They may be just experimenting or merely offering a free service. Sharing their own improvements doesn’t put them at a competitive disadvantage. But many in business find the rule more trouble than the cost of buying a commercial license. The strength of the license helps nudge them to support the product.
The AGPL is a popular choice for many of the newer projects like the various NoSQL data stores. MongoDB, for instance, adopted the license for its core tool: the database. The company chose to protect the drivers, though, with the more lenient Apache license to encourage people to link to its core offering.
Open-source to develop shared standards
Every business and marketplace needs a set of standards so that customers know what to expect and businesses know what to build. Open source can often help create these standards of interoperability.
Take HTML, the language we use for marking up documents on the Web — but also a crucial standard that allows Web browsers to compete. Once the industry coalesced around the HTML standard, browser makers were able to innovate and compete on features instead of content. Content creators, on the other hand, were assured that the Web pages they produced would generally work on all available browsers.
Open source tools often lie at the center of this evolving standard. The mobile browser marketplace, for instance, was largely defined by the WebKit rendering engine originally created by Apple but adopted by Google and others. Apple could have kept this technology proprietary, but that would have meant less interoperability between the iPhone and other smartphones, translating into fewer websites with content tailored to and rendered readable on smartphones in general. That would have slowed the marketplace. Releasing it as an open source toolkit nurtured a shared standard.
Open-source to control the future
A number of businesses, big and small, pay their employees to work on open source projects. Some even donate large blocks of code that they spent plenty of money to create. They want to make sure they influence the way the code base is developing, and the easiest way to do this is to contribute lines of code.
This influence is constant. Many of the most important contributors to all the major projects like Linux also work for companies that want to stay current. The goal, of course, is to make sure the open source code remains useful for their purposes. If the library or tool is growing, the new features may not be compatible with the company’s proprietary tools. But if the company writes a big chunk of the new features, they’ll be able to ensure it fits their needs. As Alan Kay, the inventor of the Alto, once said, “The best way to predict the future is to invent it.”