Infrequently Noted

Time 2021-09-01 20:20:34

Web Name: Infrequently Noted

WebSite: http://infrequently.org

ID:191353

Keywords:

Infrequently,Noted,

Description:

Joining a new team has surfaced just how much I've relied on a few lenses to explain the incredible opportunities and challenges of platform work. This post is the second in an emergent series towards a broader model for organisational and manager maturity in platform work, the first being last year's Platform Adjacency Theory. That article sets out a temporal model that focuses on trust in platforms. That trust has a few dimensions:Trust in reach. Does the platform deliver access to the users an app or service caters to? Will reach continue to expand at the rate computing does?Trust in capabilities. Can the platform enable the core use-cases of most apps in a category?Trust in governance. Often phrased as fear of lock-in, the goal of governance is to marry stability in the tax rate of a platform with API stability and reach.[1]These traits are primarily developer-facing for a simple reason: while the products that bring platforms to market have features and benefits, the real draw comes from safely facilitating trade on a scale the platform vendor can't possibly bootstrap on their own.Search engines, for example, can't afford to fund producing even a tiny sliver of the content they index. As platforms, they have to facilitate interactions between consumers and producers outside their walls — and continue to do so on reasonably non-extractive terms.Thinking about OSes and browsers gives us the same essential flavour: to make a larger market for the underlying product (some OS, browsers in general), the platform facilitates a vast range of apps and services by maximising developer reach from a single codebase at a low incremental cost. Those services and apps convince users to obtain the underlying products. This is the core loop at the heart of software platforms: Stewart Brand's Pace Layering model helps explain the role of platform work vs. product development.Products that include platforms iterate their product features on the commerce or fashion timescale, while platform work is the slower, higher-leverage movement of infrastructure and governance. Features added in a release for end-users have impact in the short run, while features added for developers may add cumulative momentum to the flywheel many releases later as developers pick up the new features and build new types of apps that, in turn, attract new users.This creates a predictable bias in managers towards product-only work. Iterating on features around an ecosystem becomes favoured, even when changing the game (rather than learning to play it incrementally better) would best serve their interests. In extreme versions, product-only work leads to strip-mining ecosystems for short-term product advantage, undermining long-term prospects. Late-stage capitalism loves this sort of play.The second common bias is viewing ecosystems that can't be fully mediated as somebody else's problem or as immovable. Collective action problems in open ecosystem management are abundant. Managers without much experience or comfort in complex spaces tend to lean on learned helplessness about platform evolution. Standards are slow and we need to meet developers where they are are the reasonable-sounding refrains of folks who misunderstand their jobs as platform maintainers to be about opportunities one can unlock in a single annual OKR cycle. The upside for organisations willing to be patient and intentional is that nearly all your competitors will mess this up.Failure to manage platform work at the appropriate time-scale is so ingrained that savvy platform managers can telegraph their strategies, safe in the knowledge they'll look like mad people.One might as well be playing cricket in an American park; the actions will look familiar to passers-by, but the long game will remain opaque. They won't be looking hard enough, long enough to discern how to play — let alone win.Successful platforms can extract unreasonably high taxes in many ways, but they all feature the same mechanism: using a developer's investments in one moment to extract higher rents later. A few examples:IP licensing fees that escalate, either over time or with scale.Platform controls put in place for safety or other benefits re-purposed for rent extraction (e.g. payment system taxes, pay-for-ranking in directories, etc.).Use of leverage to prevent suppliers from facilitating platform competitors in equal terms.Platforms are also in competition over these taxes. One of the web's best properties is that, through a complex arrangement of open IP licensing and broad distribution, it exerts significantly lower taxes on developers in a structural way (ceteris peribus). ↩︎ How Apple, Facebook, and Google Broke the Mobile Browser Market by Silently Undermining User Choice July 15, 2021 Updated: July 17, 2021At first glance, the market for mobile browsers looks roughly functional. The 85% global-share OS (Android) has historically facilitated browser choice and diversity in browser engines. Engine diversity is essential, as it is the mechanism that causes competition to deliver better performance, capability, privacy, security, and user controls. More on that when we get to iOS.Tech pundits and policymakers form expectations of browsers on the desktop and think about mobile browser competition the same way. To recap:Users can freely choose desktop browsers with differing features, search engines, privacy features, security properties, and underlying engines.Browsers update quickly, either through integrated auto-update mechanisms or via fast OS updates (e.g., ChromeOS).Browsers bundled with desktop OSes represent the minority of browser usage, indicating a healthy market for replacements.Popular native apps usually open links in users' chosen browsers and don't undermine the default behaviour of link clicks.[1]Each point highlights a different aspect of ecosystem health. Together, these properties show how functioning markets work: clear and meaningful user choice creates competitive pressure that improves products over time. Users select higher quality products in the dimensions they care about most, driving quality and progress.The mobile ecosystem appears to retain these properties, but the resemblance is only skin deep. Understanding how mobile OSes undermine browser choice requires a nuanced understanding of OS and browser technology. It's no wonder that few commenters are connecting the dots.[2]How bad is the situation? It may surprise you to learn that until late last year only Safari could be default browser on iOS. It may further disorient you to know that competing vendors are still prevented from delivering their own engines on iOS. Meanwhile, on Android, the #2 and #3 sources of web traffic do not respect browser choice. Users can have any browser with any engine they like, but it's unlikely to be used. The Play Store is little more than a Potemkin Village of browser choice; a vibrant facade to hide the rot.Registering to handle link taps is only half the battle. For a browser to serve as the user's agent, it must also receive navigations. Google's Search App and Facebook's various apps for Android undermine these choices in slightly different ways.[3] This reduces the effectiveness of privacy and security choices users entrust in their browsers. Developers also suffer higher costs and reduced opportunities to escape Google, Facebook, and Apple's walled gardens.Web engineers frequently refer to browsers as User Agents , a nod to their unique role as interpreters of developer intent that give users the final say over how the web is experienced. A silent erosion in the effectiveness of browser choice has transferred this power away from users, re-depositing it with dominant platforms and app publishers. To understand how this sell-out happened (quite literally) under our noses, we must look closely at how mobile and desktop differ.The Baseline Scenario #The predominant desktop situation is relatively straightforward:Browsers handle links, and non-browsers defer loading http and https URLs to the system, which in turn invokes the default browser. This flow is the central transaction that gives links power and utility. If any of the players involved (OSes, browsers, or referring apps) violate aspects of the contract, user choice in browsers becomes less effective. What, then, is a 'browser'? you might ask? I've got a long blog post brewing on this, but jumping to the end, an operable definition is:A browser is an application that can register with an OS to handle http and https navigations by default.On Android this is expressed via specific intent filters in the manifest and listing in the BROWSABLE category. iOS gained browser support in late 2020 (a dozen years late) via an Entitlement.[4] Windows and other Desktop OSes have similar (if less tidy) mechanisms.No matter how an OS technically facilitates user choice, it's this ability to choose that defines browsers as a class. How often links lead users to their preferred browser controls the meaningfulness of this choice. Modern browsers like Chrome and Samsung Internet support a long list of features that make web apps more powerful and keep users safer. Both pass all eighteen feature tests in Thomas Steiner's excellent

TAGS:Infrequently Noted 

<<< Thank you for your visit >>>

Alex Russell on browsers, standards, and the process of progress.

Hot Websites