Saturday, October 17, 2020

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.  

Friday, October 16, 2020

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.


Thursday, October 15, 2020

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.


Solution

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

FCC Section 230 should differentiate between platforms 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 amplification, regardless if it’s done through manual curation 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 now it’s time to take responsibility.

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

Wednesday, October 7, 2020

Elegant R Runtime Solution for Multithreading

Problem

A coworker came up with an elegant solution to an issue we’ve been facing with the R programing language. The R programming language is a popular open source environment for statistical computing. We run 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’s single threaded (Microsoft’s solution is R Open). A single threaded language means 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 isn’t typically an issue unless there’s a block of code that takes a long time such as a complex algorithm or a call over a network; and our application, which supports multiple users, concurrently, does both so being single threaded won't scale for us.

One solution I’ve been pursuing 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 doesn’t natively run R code; it’s better suited for Java, Python, and other languages. While it’s technically feasible to run R inside of Lambda, we hadn’t yet implemented it because it’s non-trivial.


Solution

The solution my coworker came up with was 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 which allows it to support tens of thousands of concurrent connections without incurring the cost of thread context switching.

Simple, elegant, and trivial to implement.