Network Management

Nothing to Hide, Everything to Gain

Why should a provider—particularly a content provider—care about the open standards and open source communities? There is certainly a large set of reasons why edge-focused content providers shouldn’t care about the open communities. A common objection to working in the open communities often voiced by providers runs something like this: Isn’t the entire point of building a company around data—which ultimately means around a set of processing capabilities, including the network—to hide your path to success and ultimately to prevent others from treading the same path you’ve tread? Shouldn’t providers defend their intellectual property for all the same reasons as equipment vendors?

To form an answer, it’s important to begin by differentiating between ownership and secrecy. For any technology or innovation, there are two questions that need to be asked:

  • Should we own this?
  • Should we keep this a secret?

The questions are interrelated, but not identical. Ownership is generally related to controlling your own future. Specifically, owning your architecture means the ability to intertwine your network and your business in a way that leads to competitive advantage. In contrast, handing your architecture to a vendor (almost always) means sharing their business goals with yours in some (not always obvious) way.

On the other hand, secrecy is generally related to controlling the ability of others to use your innovations to compete with you. To rephrase the second question for the open communities: Isn’t pushing modifications to an open source project or your ideas to the open standards community ultimately assisting potential competitors (new or established) in their efforts to build a bigger, better, faster network?

With the questions clarified, there are two lines of argument for active participation in the open communities—for providers, vendors, and individual engineers. The first line of argument might be called altruistic, the second might be called opportunistic. And they are more closely intertwined than they might first appear.

First, every network engineer in the world should recognize that we are all “standing on the shoulders of giants.” The folks who did the initial work of defining the protocols that run the Internet and all of our networks, today, didn’t just live off government funding. They built the companies that put their inventions into practice. From optics to protocols, these people didn’t just invent things, and they didn’t just build them—they built companies that capitalized on those inventions. In other words, they not only made themselves wealthier, they made the world wealthier, as well. At both a personal and corporate level, then, we need to offer our shoulders to future generations just as past generations have offered theirs to us. This means, in part at least, supporting open standards and open source as a natural part of building the products and companies we build now.

Failing an actual, conscious effort at building something larger than our companies and our careers, the Internet itself is far too likely to fall to the tragedy of the commons. Imagine an average village in the primarily agricultural times just a few generations ago. In each village, there would have been a green, a space shared by all to play games or hold town meetings or to hold a market. Now imagine that either one person or a small group of people in the village decide to take advantage of the “free land,” building a permanent market in the space. The entire village has lost much to the gain of a few, but there’s little that can be done. The commons are there to be used by anyone, after all.

We, as individuals and companies, want to make use of the commons—but we also need to expand the commons, lest they become ruined and the economic good they do for all, including ourselves, is removed to history. The commons of the digital world are not just the media we all share, but also the standards, source code, processes, and knowledge we have developed around building networked systems to solve problems at scale.

There is another point to be made: where and how are the next generation of engineers going to learn to build networks at scale? If we abandon the commons the open communities represent, how will we build the engineers we need to expand the scope and scale of our companies and the Internet?

Perhaps these altruistic arguments will fall flat to some section of readers—“that’s all well and good, but I’m in business to make money, not to make the world a better place, and I don’t believe the tragedy of the commons will ever really happen.” Even if the counterargument is true—there is another way to turn the argument. Participating not only helps the community, it supports the creation of the products on which your company relies.

Consider the automotive market. What would have happened if there had never been, if there weren’t today, people who take their cars out on their driveways and tinker with them? How many inventions would not have been invented, how many improvements left to the wayside? Would we still be able to buy a car in any color we want, so long as it is black?

The point is this: open communities are not only a place for creating, but also grounds for competing. The existence of the commons provides a basis for the competition that makes every piece of networking gear we buy better designed, better supported, and less expensive. When a market becomes fragmented enough that you either buy a single vendor or walk away, the market will no longer be useful for building the large-scale networks we use to build businesses. In the end, supporting open source and open standards reduces operator’s costs by increasing choice. Of course, the numbers here are impossible to quantify; perhaps something more concrete is needed to convince providers to participate.

For those who are still not convinced of the value of the open community, let me provide one more line of argument. Returning to the automotive market, suppose you were in the business of building a large delivery company. To build such a business, you need delivery vehicles. So you examine every delivery vehicle available and finally conclude that what you need to make your operations efficient doesn’t yet exist. What are your options at this point?

One way might be to wave millions of dollars of contracts in front of a manufacturer. This would only get you so far, however, for there are competing customers, perhaps even regulatory agencies, that must be persuaded to allow the vehicle you’re convinced you need to be built. But what if you were to work with other customers to develop a common core of features to which each of you could add, and around which you could all work with manufacturers and regulatory agencies to build the vehicle you need to build your business?

This common effort is precisely the open communities in the networking industry. Providers who participate in shaping open standards and open source not only help sway the market in their direction, they help build the foundations on which their businesses can be built. Further, the existence of the open community helps reduce dependence on any single vendor, thereby encouraging independence, which then feeds back into owning your own architecture.

To return to the initial question, of course there are things any provider will want to “hold back,” to not share with the larger community. There is no definite line to be drawn in deciding what to hold back for business reasons, and what to share; any such line is likely to shift over time and space in ways that are hard to define. But “difficult to define” doesn’t mean “doesn’t exist.” Several questions might be helpful in this realm, including:

  • Does this technology represent my core business?
  • Is there the chance that sharing this technology will lead to enhancements that will accelerate my ability to build a great product? This is difficult to judge, because there is no way to know what sort of community might form in any specific case or what gains might be made.

While the answers to these to questions may not be simple, we suggest tilting them in favor of the open communities rather than against. For instance, in the content provider space, the algorithms used to process data to produce the experience and information customers want would seem to be closer to the core of the business than how to build a network.

The long-standing ability of the open communities to improve on—and even revolutionize—ideas, adding value far above the investment, should convince every engineer and every company that relies on large scale networks of the open path.

No Comments to Show

Leave a Reply

Your email address will not be published. Required fields are marked *