Why the App Stores Takes a 30% Commission

Why do both the Apple App Store and Google Play stores take a 30% cut from apps they sell?

The answer is simple. When the Apple App Store launched in 2008, the going revenue share comission for content delivered to mobile phones was about 50%, give or take a few percent depending on the mobile network.

Back then, a 99¢ ring tone or $1.99 wallpaper, delivered over-the-air for mobile phone consumption, would net the developer about half of the price paid by the cell phone subscriber. The other 50% went to the mobile network provider. These charges would show up on a subscriber's phone bill as a premium SMS (PSMS).

In 2008, the PSMS market was worth about $5B/year. So, Apple's 30% take was a welcome 40% savings compared to PSMS.  

Steve Jobs User Stories: Start With the Customer Experience

Agile software development typically begins with user stories which are informal descriptions of software features from the customer's perspective (UX). When I worked at the Apple Online Store, my boss's boss would meet with Steve Jobs. Steve would tell us the user experience he wanted without trying to solution it, himself. In other words, he left the development details to the talent (developers and designers).

You got to start with the customer experience and work backwards to the technology. You can't start with with the technology and try to figure out where you're going to try to sell it. And I've made this mistake probably more than anyone else in this room and I've got the scar tissue to prove it.

– Steve Jobs

Start With Customer the Experience

In 2006, the iPod was booming along with the third party ecosystem it created. In a meeting, Steve Jobs let it be known to us that, when he was at the Apple Online Store website, he wanted to be able to see any product within three clicks. How long and how many clicks it takes to find what you're looking for is a good base metric for usability.

The challenge with three clicks, back then, was that Apple sold about two hundred different types of headphones. Displaying all of the headphones that Apple carried, at once, on a single web page would overload our servers. (Back then, there was no cloud computing.) Alternatively, paginating the results into batches of 10 or 25 wouldn't satisfy Steve's customer experience requirement. So, what to do?

One of my coworkers came across a new UI solution, infinite scrolling. Infinite scrolling allows content to load continuously as the user scrolls down the page, below the fold, eliminating the need for pagination. We now take infinite scrolling for granted on account that it's ubiquitous on popular social media sites. But, back then, it was new and it turned out to be the perfect solution for Steve.

Section 230 Solution: My Thoughts On Content Service Providers vs Publishers

Summary

The current state of social media reminds me of the early days of e-mail in the late 1980s and throughout the 1990s. E-mail was a godsend in that we could communicate with people around the world in a matter of seconds; but security and spam were out of control. It was the Wild West. Now, we have an opportunity to fix social media the same way we fixed e-mail, through laws, technology, and regulation

Background

Section 230(c)(1) provides immunity from liability for providers and users of an "interactive computer service" who publish information provided by third-party users:

No provider or user of an interactive computer service shall be treated as the publisher or speaker of any information provided by another information content provider.

This protects social media websites since they’re not generating content like a news service. But, there’s obviously a problem since misinformation can be promulgated as truth, typically faster than fact. Also, the more content is amplified, the more authority it has, even if it’s false information. This is know as Brandolini's law.

Solution

Here’s my solution that doesn’t violate the First Amendment:

FCC Section 230 should differentiate between platforms and actions that amplify content (e.g. retweeting on Twitter, resharing on Facebook, etc) and platforms that don’t allow amplification (e.g. Instagram, WordPress, etc). If a platform allows content amplification or curation, regardless if it’s done manually or via an automated algorithm, then it’s no longer a service provider but rather a publisher.

If this degree of editing and censorship sounds like an administrative burden then take a look at the lack of child porn found through search engines like Google, Bing, Yahoo, etc. There is none, but certainly not from a lack of trying. And while the CAN-SPAM Act doesn't eliminate all spam, it does a great job (certainly much better than the wireless network providers when it comes to spoofing caller ID, etc).

Just as a news service doesn’t pass along fact as fiction without liability (libel) neither should social media. This clarification to Section 230 will cut into the profitability of social media companies, but they’ve reaped the benefits (and revenue) and it’s time to be more responsible now that we understand its impact on our way of life.  

This post began as a tweet, but Twitter is down.

Elegant R Runtime Solution for Multithreading

 The Problem

The R programming language is a popular open source environment for statistical computing. CANA runs multiple R algorithms on a server using the Plumber framework, which converts existing R code into web APIs by adding a couple of special comments. A key issue with R is that it is single threaded, meaning that only a single block of code, inside an application, can execute at any given time. In other words, while that single block is executing, all other code is blocked. This is not typically an issue unless there is a block of code that takes a long time, such as a complex algorithm or a call over a network. CANA’s application performs both, and supports multiple users concurrently, so being single threaded does not scale for us.

One solution I pursued over the last year was to use the AWS Lambda service which allows standalone functions to execute in the cloud. The challenge with Lambda is it does not natively run R code and is better suited for Java, Python, and other languages. While it is technically feasible to run R inside of Lambda, we had not yet implemented it because it is non-trivial, requiring that R run inside a Python container with supporting frameworks and libraries.

R Multithreading Solution

A coworker came up with an elegant solution to this programming problem. The solution is to run a Node.js server that simply makes calls to shell scripts (R scripts) running on the host operating system. Each shell script runs in its own process, so one won’t block another. And, even though Node.js is, itself, single threaded, it uses non-blocking input/output calls (“callbacks”), allowing it to support tens of thousands of concurrent connections without incurring the cost of thread context switching.

Simple, elegant, and trivial to implement.