How to lockdown a platform

Epic Games, the video game publisher behind Fortnite, recently sued Apple for disallowing alternatives to the Apple App Store for processing microtransactions while simultaneously imposing a 30 percent transaction fee. While the case and specifics are new, criticism of Apple’s “Walled Garden” is all too familiar. This poetic expression of “Walled Garden” refers to Apple’s practice of closed platforming, where a company restricts third-party competition or development, and Apple is far from the only practitioner. Intel, Nintendo, and Nvidia have all faced similar criticism at some point.

Closed platforming has its benefits and downsides. When a company focuses only on supporting their own platform, software development can occur much more quickly and consistently since wide-scale software compatibility beyond the platform does not need to be considered. This also reduces the associated cost for a company. New features can be implemented more rapidly since there is less variation in how a developer accesses and learns about a new feature. For users, closed platforming typically results in a more consistent and simplified way of interfacing with their devices and software due to a primarily custom codebase. For example, Apple’s HomePod can create a reminder when asked on your Calendar that pairs with your MacBook and iPhone which will notify you through your AirPods around the appropriate time, something very difficult to do on other platforms. While it is certainly possible to achieve similar advantages to closed platforming through open platforming, it is typically more difficult. Nevertheless, many see open platforming as the superior choice due to closed platforming’s many downsides.

Closed platforming inherently reduces market competition by increasing the barrier of entry for app developers and users alike while simultaneously restricting consumer choice by making alternatives less likely. Closed platforming also binds both consumers and developers to a platform by isolating users into a niche ecosystem which can make porting to other platforms difficult if not outright impossible. Developers are also forced to take on a level of inflexibility since closed platforming isolates an individual programmer from the broader programming community. The developer is then dependent on an outside company for new features and bug fixes.

However, most of these downsides only apply to developers and consumers, so it is common to see companies with a dominant portion of market share switch at least to a semi-closed platform until encouraged otherwise through backlash or a receding market share. So, it is imperative to highlight what practices should and should not be followed in the industry to reduce the growing pains associated with such a transition:

Make development easy.

If a company makes a transition to their closed platform unnecessarily difficult, it greatly reduces willingness to work with said platform. For example, when attempting to develop with an Intel Xeon Phi 71S1P Coprocessor—a PCI-Express many-core/highly parallelized processor—using OpenMP, a library for parallel programming, I found that Intel forces developers to buy a license to a compiler costing around $400-500 just to be allowed to program the device the individual has already bought. This notion of charging a developer to compile code just to test out a platform is ridiculous in my mind and made development with the platform unnecessarily difficult. This frustration combined with the headache associated with setup and lackluster performance improvements left no question why the product lineup was later discontinued.

Maintain compatibility with supported standards whenever possible.

When developing a new application, developers will strive to use whatever gives them the best performance and development experience. So, if a company wants to encourage people to use their standard, they should simply add support for new software and hardware features within the proprietary standard as opposed to artificially dropping existing support which prevents adoption of the platform in general. Nvidia did the opposite with the GTX 1000 Visual Profiler 5.0, a code profiler which measured the performance characteristics of applications. Nvidia opted to no longer support OpenCL profiling. OpenCL is a programming language and library for general-purpose computation using graphics processors. One may speculate that this is due to some new change in hardware preventing it from functioning, but this notion is contradicted by the fact that a third-party fix can be used to get OpenCL profiling working by simply tricking the software into thinking that the executable came from a CUDA application (CUDA is a Nvidia-specific language and library). I ran into this issue when performing performance analysis on MilkyWay@Home’s GPU version, a software client for the MilkyWay@Home distributed computing project running n-body simulations. The painful experience was enough to make me look at alternatives such as AMD as my platform of choice.

Develop a good ecosystem.

The OpenSSL library provides features for web cyber security. One of these features is a cryptography suite that can be used for arbitrary hashing-a one-way pseudo-random, deterministic method of encoding information similar to a cypher ring. Unfortunately, the library is known to have compatibility issues across releases due to its inconsistent interface causing several problems in codebases I have worked with. Seeing this issue with the library, Apple decided to make their own cryptography library called Common Crypto and provided developers with several resources to learn how to easily implement this new library into their codebases for superior performance, support, and ease of use. In this case, Apple saw an opportunity to better upon an open source library for their devices and did so.

In short, if one transitions to closed platforming, make sure the “Walled Garden” is one that’s easy to access and use.