Technological Platform Capital

by Gigs Taggart, Correspondent

Gigs Taggart (Jason Giglio) is an active member of the Second Life community as a scripter and contributor to the OpenSL project, land developer, and proprietor of GT HQ Store and Arcade.

In classical economics, the four factors of production are capital, labor, land, and enterprise. Capital started out as a simple concept, it represented the manufactured goods that allowed the production of other manufactured goods. It later evolved to include some fuzzier concepts, such as human capital, knowledge capital, (physical) infrastructure capital, and social capital.

Here I propose a new type of capital, technological platform capital. Linden Lab’s Second Life is a self-contained technological platform with a microcosm economy that provides an ideal example to develop this concept.

In Second Life, retail products are entirely reliant on platform features in order to serve their purpose. These features include, but are not limited to, the 3D build environment that allows aesthetic and functional elements to be constructed visually, the micropayment system which allows money to be transferred easily, and the scripting system which allows the objects to execute built-in software.

I will make a distinction here. Not all features can be considered capital. Some features of the platform exist to facilitate social interaction, usability, or improve the general environment. These “end-user” features, while important, do little to add to the technological platform capital that is available. End users, which must, by necessity, outnumber developers, often demand these sorts of features from the platform provider.

Second Life is both a platform and a retail product, and therefore has these competing interests. This is becoming more and more common. Operating systems, for example, are also both a platform and an end-user product, as are many hardware devices. Such hybrid platforms need to balance the viability as a platform, and the viability as a retail product.

Technological platform capital has some unique properties that make this balancing act easier:

• It is not exhausted with utilization, unless it relies on a centralized resource (such as a central web service).
• It exhibits a “network effect” with regard to its value and return on investment.
• It enables third parties to provide missing end-user features.

Unlike traditional capital, platform capital does not have much, or any marginal cost to provide in many cases. There are exceptions, such as requiring extra hardware chips, or relying on the scalability of a centralized service, but many features, especially software features, do not have this marginal cost. Once a feature is written, all developers reap the benefit, and end-users reap the benefit indirectly.

Robert Metcalfe originally coined the term “network effect” when referring to the cost vs benefit of Ethernet networking cards. Expressed mathematically, he posited that the cost grew linearly (n), but the benefit grew parabolically (n^2). Platform capital has a similar dynamic.

Features often compliment each other in ways that approximate the network effect. Some features are mainly orthogonal to others, so instead of a hard progression we can only calculate the upper bound of benefit. Third-party products on a platform can be viewed as mathematical combinations of the available features. This can be up to and including every feature, therefore it follows the same rules for combination without repetition, namely:

nCr or n!/(r!(n-r)!)  (where r is the number of features used in the product)

This upper bound is smaller than n^2, but still a very large marginal benefit per new platform capital feature.

This is offset by the cost being nearly fixed rather than linear. Because lack of exhaustion of resource is inherent in most features, the cost is closer to fixed than it is to linear. There is some cost in maintaining a feature over time, but such cost, while large in comparison to the initial development cost, does not depend on the number of products utilizing the feature, and can be considered fixed rather than variable.

The third point is probably the most important one. As mentioned before, there is often demand on a hybrid platform provider to provide immediate end-user features. Such features are highly visible, widely demanded, and often widely praised. There is a strong temptation to invest development efforts on these features, while letting platform capital features stagnate. This is a bad strategy because platform capital, in addition to its above benefits, provides the tools for third parties to provide the missing end-user functionality.

The best case benefit from an end-user feature is linear. The cost is higher than a platform feature because end-users generally have differing and vague expectations and needs from the feature. This process of communicating with the user, and maintaining the feature to suit changing and sometimes conflicting needs is time consuming and costly and bloat inducing. In contrast, platform capital features are generally well defined and serve a specific purpose within the platform. A focus on end-user features also pits the platform provider as a competitor of the third party developer, rather than a vendor. Nowhere is this more obvious than with Microsoft Windows. Microsoft often uses this intentionally to stifle companies that use their platform that may also pose a threat to their platform or other product lines. Microsoft is a special case, however. Other platform providers generally do not intend to compete with developers that use their platform. They may do so unintentionally when they pursue end-user features.

A strong focus on platform capital—rather than end-user features—should be the goal of any platform provider. End-user features divert resources away from more beneficial platform capital development, pit provider against developer, and serve the end-user’s needs in ways that directly addressing their needs never can.

* * *