Mel Conway's seminal paper "How Do Committees Invent?" (PDF) is commonly paraphrased as Conway's Law:

Organizations which design systems are (broadly) constrained to produce designs which are copies of the communication structures of these organizations.

This is deep organisational insight that engineering leaders ignore at their peril, and everyone who delivers code for a living benefits from a (re)read of "The Mythical Man-Month", available at fine retailers everywhere.

In most contexts, organisations invoking it are nominally engaged in solving a defined problem, and everyone participating is working towards a solution. But what if there are defectors? And what if they can prevent all forward progress without paying any price? This problem is rarely analysed for the simple reason that such an organisation would be deranged.

But what if that happened regularly?

I was reminded of the possibility while chatting with a colleague joining a new (to them) Working Group at the W3C. The most cursed expressions of Conway's Law regularly occur in Standards Development Organisations (SDOs); specifically, when delegates refuse to communicate their true intentions, often through silence.

This special case is the fifth column problem.

Expressed in Conwayist terms, the fifth column problem describes the way organisations mirror the miscommunication patterns of their participants when they fail to deliver designs of any sort. This happens most often when the goal of the majority is antithetical to a small minority who have a veto.

Reticence of certain SDO participants to consider important problems is endemic because of open membership. Unlike corporate environments where alignment is at least partially top-down, the ability of any firm to join an SDO practically invites subterfuge. This plays out through representatives of pivotal firms obfuscating their willingness to implement, or endlessly delaying consideration of important designs.

Open membership alone would not lead to crisis, except that certain working groups adopt rules or norms that create an explosion of veto players.

These veto-happy environments combine with bad information to transmute opaque communication into arterial blockage. SDO torpidity, in turn, colours the perception of web developers against standards. And who's to say they're wrong? Bemoaning phlegmatic working groups is only so cathartic. Eventually, code has to ship, and if important features are missing from standards-based platforms, proprietary alternatives become inevitable.

Instances of the fifth column problem are frequently raised to me by engineers working in these groups. "How," they ask, "can large gatherings of engineers meet regularly, accomplish next-to-nothing, yet continue pat themselves on the back?"

The sad answer is "quite easily."

This dynamic has recurred with surprising regularity over the web's history,¹ and preventing it from clogging the works is critical to the good order of the entire system.

How Does This Happen?

The primary mechanism that produces consequential fifth column episodes is internal competition within tech giants.

Because the web is a platform, and because platforms are competitions, it's natural that companies which produce both browsers and proprietary platforms favour their owned-and-operated offerings.

The rent extraction opportunities from controlling OS APIs are much more lucrative than an open ecosystem's direct competition. Decisions about closed platforms also do not have to consider other players as potential collaborators. Strategically speaking, managing a proprietary platform is playing on easy mode. When that isn't possible, the web can provide a powerful bridge to the temporarily embarrassed monopolist, but that is never their preference.

This competition is often hard to see because the jousting between proprietary systems and open platforms takes place within the most heavily guarded processes of tech giants: budget planning.

Because budgets are secret, news of the web losing status is also a secret. It's a firing offence to leak budget details, or even share internally to those without a need to know, so line engineers may never be explicitly told that their mission has fundamentally changed. They can experience transitions away from the web as "Plan A" to "Plan Z" without their day-to-day changing much. The team just stops growing, and different types of features get priority, but code is still being written at roughly the same rate.

OS vendors that walk away from the web after it has served their businesses can simply freeze browser teams, trimming ambitions around the edges without even telling the team that their status has been lowered. Capping and diverting funding away from new capabilities is easily explained; iteration on existing, non-threatening features is always important, after all, and there are always benchmarks to optimise for instead.

Mayfly Half-Lives

Until recently, the impact of fifth column tactics was obscured in a haze of legacy engines. Web developers take universality seriously, so improvements in capabilities have historically been experienced as the rate at which legacy UAs fall below a nominal relevance threshold.² Thanks to pervasive auto-updates, the historical problem of dead-code-walking has largely been resolved. Major versions of important browsers may have entire cradle-to-grave lifecycles on the order of two or three months, rather than IE 6's half-decade half-life.

This has clarified the impact of (dis)investments by certain vendors and makes fifth columnists easier to spot. Web developers now benefit from, or are held back by, recent decisions by the companies (under)funding browser development. If sites remain unable to use features launched in leading-edge engines, it's only because of deficiencies in recent versions of competing engines. This is a much easier gap to close — in theory, anyway.

The Web Platform's Power Structure

Web standards are voluntary, and the legal structures that create SDO safe-harbours (PDF) create the space in, and rules under, which SDOs must operate. SDOs may find their designs written into legislation after the fact, or as implementation guides, but there is a strong aversion to being told what to design by governments within the web community, particularly among implementers. Some new participants in standards arrive with the expectation that the de jure nature of a formal standard creates a requirement for implementation, but nothing could be further from fact. This sometimes leads to great frustration; enshrining a design in a ratified standard does not obligate anyone to do anything, and many volumes of pure specifiction have been issued over the decades to little effect.

The voluntary nature of web standards is based on the autonomy of browsers, servers, and web developers to implement whatever they please under own brand.

Until Apple's flagrantly anticompetitive iOS policies, this right was viewed as inviolable because, when compromised, erosions of feature sovereignty undermines the entire premise of SDOs.

When products lose the ability to differentiate on features, quality, performance, safety, and standards conformance, the market logic underpinning voluntary standards becomes a dead letter. There's no reason to propose an improvement to the collective body of the web when another party can prevent you from winning share by supporting that feature.

The harms of implementation compellence are proportional to market influence. iOS's monopoly on the pockets of the wealthy (read: influential) has decisively undermined the logic of the open internet and the browser market. Not coincidentally, this has also desolated the prospect of a thriving mobile web.

The Mobile Web: MIA

It's no exaggeration to say that it is anti-web to constrain which standards vendors can implement within their browsers, and implementation coercion is antithetical to the good functioning of SDOs and the broader web ecosystem.³

In a perverse way, Apple's policy predations, strategic under-investment, and abusive incompetence clarify the basic terms of the web's power structure: SDOs are downstream of browser competition, and browser competition depends on open operating systems.

But Why?

Why do vendors spend time and money to work in standards, only to give away their IP in the form of patent licences covering ratified documents?

When vendors enjoy product autonomy, they develop standards to increase interoperability at the behest of customers who dislike lock-in. Standards also lower vendor's legal risk through joint licensing, and increase marketability of their products. Behind this nondescript summary often lies a furious battle for market share between bitter competitors, and standards development is famous for playing a subtle role. Shapiro and Varian's classic paper "The Art of Standards Wars" (PDF) is a quarter-century old now, but its description of these sorts of battles is no less relevant today that it was in '99.

Like this classic, many discussions of standards battles highlight two parties with differing visions — should margin-sizing or border-sizing be the default? — rather than situations where one vendor has a proprietary agenda. These cases are under-discussed, in part, because they're hard to perceive in short time windows or by evaluating only at one standard or working group.

Parties that maintain a footprint in standards, but are unhappy to see standards-based platforms compete with their proprietary offerings, only need a few pages from the Simple Sabotage manual (PDF).

Often, they will send delegates to important groups and take visible leadership positions. Combined with juuuuuust enough constructive technical engagement, obstreperous parties scarcely have to say anything about their intent. Others will raise their own hopes, and cite (tepid) participation as evidence of good faith. The fifth columnist doesn't need to raise a finger, which is handy, as doing nothing is the goal.⁴

Problem Misstatements

Working group composition also favours delays at the hands of fifth columnists. Encouraged by defectors, they regularly divert focus from important problems, instead spending huge amounts of time on trivialities because few customers (web developers) have the time, money, and energy to represent their own needs in committee. Without those voices, it's hard to keep things on track.

Worse, web developers generally lack an understanding of browser implementation details and don't intone the linguistic airs and shorthands of committeespeak, which vary from venue to venue. This hampers their ability to be taken seriously if they do attend. At the limit, dismissing pressing problems on technicalities can become something of a committee pastime.⁵

There's also a great deal of opportunity for fifth columnists to misrepresent the clearly stated needs of web developers, launching projects to solve adjacent (but unimportant) sub-issues, while failing to address the issues of the day. This is particularly problematic in big, old rooms.

A competent fifth columnist only needs to signal in-group membership to amplify the impact of their own disinterest in topics they would prefer to avoid. Ambiguous "concerns" and scary sounding caveats are raised, and oven-ready designs which do arrive are reframed as naive proposals by outsiders. Process-level critique, in lieu of discussing substance, is the final line of defence.

Deflecting important work is shockingly easy to pull off because organisations that wish to defeat progress can send delegates that appealing to rooms full of C++/Rust engineers as equals. The tripwires in web API design are not obvious to the uninitiated, so it's easy to move entire areas of design off the agenda through critique of small, incongruent details.

The most depressing thing about this pattern is that these tactics work because other vendors allow it.

Closed For Business

One problem facing new areas in standards is that chartered Working Groups are just that: chartered. They have to define what they will deliver years in advance, and anything not on the agenda is, by definition, not in scope. The window in many SDO processes for putting something new into the hopper is both short and biased towards small revisions of the existing features. Spinning up new Working Groups is a huge effort that requires political clout.

Technically, this is a feature of SDOs; they jointly licence the IP of members to reduce risks to implementers and customers of adopting standards-based products. Patent trolls have to consider the mutual defences of the whole group's membership and cannot easily pick off smaller prey. Given that most (customers) web developers never give a second thought to patent portfolios, and have never been personally sued for infringement — a sign web standards are a smashing success — they are unlikely to understand that the process is designed with bounded IP commitments in mind.

This creates a tension: over the long term, SDOs and the ecosystems can only succeed if they take on new problems that are adjacent to the current set, but the Working Groups they create are primed by their composition and history to avoid taking on substantial expansions of their scope. After all, a good v2 of a spec is one that fixes all the problems of v1 and introduces relatively few new ones.

To work around this restriction, functional SDOs create incubation venues. These take different guises, but the core features are the same. Unlike chartered Working Groups, incubation groups are simple to create; no charter votes or large, up-front IP commitments. They also feature low bars to participation, can be easily shut down, and do not produce documents for formal standardization, although they can produce "Notes" or other specification documents that Working Groups can take up.

Instead, they tend to have substantial contributor-only grants of IP, ad-hoc meeting and internal debate mechanisms, and attract only those interested in working on solutions in a new problem space. In functioning SDOs, such "fail-fast" groups naturally become feeders for chartered Working Groups, iterating on problems and solutions at a rate which is not possible under the plodding bureaucracy of a chartered Working Groups's minuted and agenda-driven meeting cadence.

And that's why these sorts of groups are a first priority for sabotage by fifth columnists. The usual tactics deployed to subvert incubation include:

• Aspersions of bad faith by those working in incubation venues, either on the grounds that the groups are "amateur", "not standards-track",⁶ or "do not have the right people."
• Avoidance of engagement in incubation groups, robbing them of timely feedback while creating the self-fulfilling lack of expertise critique.
• Claiming that a high fraction of designs that fail in these groups as an indicator that they are not useful, rather than the reality that the entire point of incubation is to fail fast and iterate furiously.
• Accuse those who implement incubated proposals of "not following the process", "ignoring standards", or "shipping whatever they want"; twisting the goals of those doing design in the open, in good faith, under the SDO's IP umbrella.
• Demanding formalities akin to chartered Working Groups to slow the pace of design progress in incubation venues that are too successful to ignore.

The fifth columnist also works behind the scenes to reduce the standing and reputation of incubation groups among the SDO's grandees, claiming that they represent a threat to the stability of the overall organisation. Because that constituency is largely divorced from the sausage-making, this sort of treachery works more often than it should, causing those who want to solve problems to burn time defending the existence of venues where real progress is being made.

Survivorship Bias and The Problem of Big, Old Rooms

The picture presented this far is of Working Groups meeting in The Upside Down. After all, it's only web developers who can provide a real test of a design, or even the legitimacy of a problem.

This problem becomes endemic in many groups, and entire SDOs can become captured by the internal dramas and preferences of implementers, effectively locking customers out. Without more dynamic, fail-fast forums that enable coalitions of the willing to design and ship around obstructionists, working groups can lay exclusive claim to important technologies and retreat into irrelevance without paying a reputational cost.

The alternative — hard forking specifications — is a nuclear option. The fallout can easily blow back into the camp of those launching a fork, and the effort involved is stupendous. Given the limited near-term upside and unclear results, few are brave or foolish enough to consider forking to route around a single intransigent party.

This feeds the eclipse of an SDO's relevance because legitimacy deficits become toxic to the host only slowly. Risk of obsolescence can creep unnoticed until it's too late. As long as the ancient forms and traditions are followed, a decade or more can pass before the fecklessness of an important group rises to the notice of anyone with the power to provoke change. All the while, external observers will wonder why they must resort to increasingly tall piles of workarounds and transpilers. Some may even come to view deadening stasis, incompatibility, and waste as the natural state of affairs, declining to invest any further hope for change in the work of SDOs. At this point, the fifth columnist has won.

One of the self-renewing arrows in the fifth column's arsenal is the tendency of large and old working groups to indulge in survivorship bias.

Logically, there's no reason why folks whose designs won a lottery in the last round of market jousting⁷ should be gatekeepers regarding the next tranche of features. Having proposed winning designs in the past is not, in itself, a reliable credential. And yet, many of these folks become embedded within working groups, sometimes for decades, holding sway by dint of years of service and interpersonal capital. Experience can be helpful, but only when it is directed to constructive engagement, and too many group chairs allow bad behavior, verging on incivility, at the hands of la vieille garde. This, of course, actively discourages new and important work, and instead clears the ground for yet more navel-gazing.

This sort of in-group/out-group formation is natural in some sense, and even folks who have loathed each other from across a succession of identically drab conference rooms for years can find a sort of camaraderie in it. But the social lives of habitual TPAC and TC39 attendees are no reason to accept unproductive monopolies on progress; particularly when the folks in those rooms become unwitting dupes of fifth columnists, defending the honour of the group against those assailing it for not doing enough.

The dysfunctions of this dynamic mirrors those of lightly moderated email lists: small rooms of people all trying to solve the same problem can be incredibly productive, no matter how open. Large rooms with high alignment of aims can make progress if leadership is evident (e.g., strong moderation). What is reliably toxic are large, open rooms with a mix of "old timers" who are never moderated and "newbies" who have no social standing. Without either a clear destination or any effective means of making decisions, these sorts of venues become vitriolic over even the slightest things. As applied to working groups, without incredibly strong chairing, interpersonal dynamics of long-standing groups can make a mockery of the responsibilities resting on the shoulders of charter. But it's unusual for anyone on the outside to get any the wiser. Who has time to decipher meeting minutes or decode in-group shorthands?

And so it is precisely because fifth columnists can hire old timers⁸ that they are able to pivot groups away from addressing pressing concerns to the majority of the ecosystem, particularly in the absence of functional incubation venues challenging sclerotic groups to move faster.

Marketing Gridlock As Thoughtfulness

One useful lens for discussing the fifth column problem is the now-common Political Science analysis of systems through "veto points" or "veto players" (Tsebelis, '95; PDF):

Policy stability is different from both government stability and regime stability. In fact ... they are inversely related: policy stability causes government or regime instability. This analysis is based on the concept of the veto player in different institutional settings.

If we substitute "capability stability" for "policy stability" and "platform relevance" for "government/regime stability," the situation becomes clear:

Capability stability is different from platform relevance. In fact ... they are inversely related: capability stability causes platform irrelevance.

Any platform that cannot grow to incorporate new capabilities, or change to address pressing problems, eventually suffers irrelevance, then collapse. And the availability of veto points to players entirely hostile to the success of the platform is, therefore, an existential risk⁹ — both to the platform and to the SDOs that standardise it, not to mention the careers of developers invested in the platform.

This isn't hard to understand, so how does the enterprising fifth columnist cover their tracks? By claiming that they are not opposed to proposals, but that they "need work," without either offering to do that work, develop counter-proposals, or make any commitment to ship any version of proposals in their own products. This works too often because a pattern of practice must develop before participants can see that blockage is not a one-off rant by a passionate engineer.

Participants are given wide births, both because of the presumption of voluntarity implementations,¹⁰ and the social attitudes of standards-inclined developers. Most SDO participants are community-minded and collaboration-oriented. It's troubling to imagine that someone would show up to such a gathering without an intent to work to solve problems, as that would amount to bad faith. But it has recurred frequently enough that we must accept it does happen. Having accepted its possibility, we must learn to spot the signs, remain on guard, and call it out as evidence accumulates.

The meta-goal is to ensure no action for developers, with delay to the point of irrelevance as a fallback position, so it is essential to the veto wielder that this delay be viewed as desirable in some other dimension. If this sounds similar to "but neighbourhood character!" arguments by NIMBYs offer, that's no accident. Without a valid argument to forestall efforts to solve pressing problems, the fifth column must appeal to latent, second-order values that are generally accepted by the assembled to pre-empt the first-order concern. This works a shocking fraction of the time.

It works all the better in committees with a strong internal identity. It's much easier to claim that external developers demanding solutions "just don't get it" when the group already views their role as self-styled bulwarks against bad ideas.

When Is A "Consensus" Not Consensus?

The final, most pernicious, building block of Working Group decay is the introduction of easy vetoes, most often via consensus decision-making. When vetoes are available to anyone in a large group at many points, the set of proposals that can be offered without a presumption of failure shrinks to a tiny set, in line with the findings of Tsebelis.

This is not a new problem in standards development, but the language gets muddy, so for consistency's sake we'll define two versions:

• Strong Consensus refers to working modes in which the assent of every participant is affirmatively required to move proposals forward.
• Weak Consensus are modes in which preferences are polled, but "the sense of the room" can carry a proposal forward over even strenuous objections by small minorities.

Every long-term functional SDO operates by some version of Weak Consensus. The IETF bandies this about so often that the phrase "rough consensus and running code" is synonymous with the organisation.

But not every group within these SDOs are chaired by folks willing to overrule objectors. In these situations, groups can revert to de facto strong consensus, which greatly multiplies the number of veto holders. Variations on this theme can be even less disciplined, with only an old guard having effective veto power, whilst newer participants may be more easily overturned.

Strong consensus is the camel's nose for long-term gridlock. Like unmoderated mailing lists, things can spiral without anyone quite knowing where the error was made. Small groups can start under strong consensus out of a sense of mutual respect, only to find it is nearly impossible to revoke a veto power once handed out. A sense of fair play may cause this right to be extended to each new participant, and as groups grow, affiliations change, and interests naturally diverge, it may belatedly dawn on those interested in progress that the very rooms where they once had so much luck driving things forward have become utterly dysfunctional. And under identical rules!

Having found the group no longer functions, delegates who have invested large portions of their careers to these spaces have a choice: they can acknowledge that it is not working and demand change, becoming incredibly unpopular amongst their closest peers in the process. Or they can keep their heads down and hope for the best, defending the honour of the group against attacks by "outsiders". Don't they know whose these people are?

Once it sets in, strong consensus modes are devilish to unpick, often requiring a changing of the guard, both among group chairs and influential veto-wielders. Groups can lose internal cohesion and technical expertise in the process, heaping disincentive to rock even the most unproductive boats.

Defences Against Fifth Columns

The ways that web ecosystem SDOs and their participants can guard against embrittlement and fracture from the leeching effects of fifth columns are straightforward, if difficult to pull off socially:

• Seek out and remove strong consensus processes.

  The timeless wisdom of weak consensus is generally prescribed by process documents governing SDOs, so the usual challenge is enforcement. The difficulty in shaking strong consensus practices is frequently compounded by the status of influential individuals from important working groups who prefer it. Regardless, the consequences of allowing strong consensus to fester in rooms big enough to justify chairing is dire, and it must be eliminated root and branch.

• Aggressively encourage "counterproposal or GTFO" culture.

  Fifth columnists thrive in creating ambiguity for the prospects of meaningful proposals while paying no cost for "just asking questions." This should be actively discouraged, particularly among implementers, within the social compact of web SDOs. The price for imposing delay must be higher than having vague "concerns".

• Require Working Groups to list incubators they accept proposals from. Require they prove it.

  Many groups that fifth columnists exploit demonstrate a relative imperviousness to new ideas through a combination of social norms and studious ignorance. To break this pattern, SDOs should require all re-charters include clear evidence of proposals coming from outside the group itself. Without such collateral, charters should be at risk.

• Defend incubators from process attacks.

  Far from being sideshows, incubation venues are the lifeblood of vibrant SDOs. They must be encouraged, nurtured, and highlighted to the membership as essential to the success of the ecosystem and the organisation.

  In the same vein, process shenanigans to destabilise successful incubators must be fended off; including but not limited to making them harder to join or create, efforts to deny their work products a seat in working group chartering, or tactics that make their internal operations more veto-centric.

It takes a long time, but like the gravitational effects of a wandering planet out in the OORT cloud, the informational content of the fifth columnist's agenda eventually becomes legible by side effect. Because an anti-web agenda is easy to pass off under other cover, it requires a great number of observations to understand that this part of the committee does not want the platform to evolve. From that point forward, it becomes easier to understand the information being communicated as noise, rather than signal.

Once demonstrated, we must route around the damage, raising the cost of efforts to undermine the single most successful standards-based ecosystem of our lifetimes; one that I believe is worth defending from insider threats as well as external attack.

---

1. The most substantial periods of institutional decrepitude in web standards are highly correlated with veto players (vendors with more than ~10% total share) walking away from efforts to push the web forward.

   The most famous period of SDO decay is probably the W3C's troubled period after Microsoft disbanded the IE team after IE 6.0's triumphant release in 2001. Even if folks from Microsoft continued to go to meetings, there was nobody left to implement new or different designs and no product to launch them in.

   Standards debate went from pitched battles over essential features of systems being actively developed to creative writing contests about futures it might be nice to have. Without the disciplining function of vendors shipping, working groups just become expensive and drab pantomimes.

   With Microsoft circa 2002 casting the IE team to the wind and pivoting hard to XAML and proprietary, Windows-centric technologies, along with the collapse of Netscape, the W3C was left rudderless, allowing it to drift into failed XHTML escapades that inspired revulsion among the remaining staffed engine projects.

   This all came to a head over proposed future directions at 2004's Web Applications and Compound Document Workshop. WHATWG was founded in the explosion's crater, and the rest is (contested) history.

   The seeds of the next failure epoch were planted at the launch of the iOS App Store in 2008, where it first became clear that other "browsers" would be allowed on Cupertino's best-selling devices, but not if they included their own engines. Unlike the big-bang of Microsoft walking away from browsers for 3+ years, Apple's undermining of the W3C, IETF, and ECMA become visible only gradually as the total global market share of mobile devices accelerated. Apple also "lost" its early lead in the smartphone market share as Android ate up the low end's explosive growth. The result was a two-track mobile universe, where Apple retained nearly all influence and profits, whilst most new smartphone users encountered the predations of Samsung, HTC, LG, Xiaomi, and a hundred other cut-price brands.

   Apple's internal debates about which platform for iOS was going to "win" may have been unsettled at the launch of the App Store¹², but shortly thereafter the fate of Safari and the web on iOS was sealed when Push Notifications appeared for native apps but not web apps.

   Cupertino leveraged its monopoly on influence to destroy the web's chances, while Mozilla, Google, and others who should have spoken up remained silent. Whether that cowardice was borne of fear, hope, or ignorance hardly matters now. The price of silence is now plain, and the web so weakened that it may succumb entirely to the next threat; after all, it has no champions among the megacorps that have built their businesses on its back.

   First among equals, Apple remains at the vanguard of efforts to suppress the web, spending vast sums to mislead web developers, regulators, legislators, and civil society. That last group uncomfortably includes SDOs, and it's horrifying to see the gaslighting plan work while, in parallel, Cupertino sues for delay and offers easily disproven nonsense in rooms where knowing misrepresentation should carry sanction.

   All this to preclude a competent version of the web on iPhones, either from Apple or (horrors!) from anyone else. Query why. ⇐

2. The market share at which any browser obtains "blocking share" is not well theorized, but is demonstrably below 5% for previously dominant players, and perhaps higher for browsers or brands that never achieved market plurality status.

   Browsers and engines which never gain share above about 10% are not considered "relevant" by most developers and can be born, live, and die entirely out of view of the mainstream. For other players, particularly across form-factors, the salience of any specific engine is more contextual. Contractual terms, tooling support, and even the personal experience of influential developers all play a role. This situation is not helped by major sites and CDNs — with the partial exception of Cloudflare — declining to share statistics on the mix of browsers their services see.

   Regardless, web-wide market share below 2% for any specific version of any engine is generally accepted as irrelevance; the point at which developers no longer put in even minimal effort to continue to support a browser except with "fallback" experiences. ⇐

3. It's not an exaggeration to suggest that the W3C, IETF, and ECMA have been fundamentally undermined by Apple's coercion regarding browser engines on iOS, turning the entire organisation into a sort of Potempkin village with semi-independent burgs taking shape on the outskirts through Community Groups like the WICG,, which Apple regularly tries to tear down through procedural attacks it hopes the wider community will not trace back to the source.

   When competitors cannot ship their best ideas, the venues where voluntary standards are codified lose both their role as patent-pooling accelerators for adoption, as well as their techno-social role as mediators and neutral ground.

   The corporeal form continues long after the ghost leaves the body, but once the vivvifying force of feature autonomy is removed, an SDO's roof only serves to collect skeletons, eventually compromising the origanisation itself. On these grounds, self-aware versions of the W3C, IETF, and ECMA would have long ago ejected Apple from membership, but self-awareness is not their strong suit. And as long as the meetings continue and new drafts are published, it hardly deserves mention that the SDO's role in facilitating truly disruptive change will never again be roused. After all, the membership documents companies sign do not require them to refrain from shivving their competition; only that everyone keep their voices down and the tone civil.

   What's truly sad is how few convening services or reading the liturgy from the pews seem disturbed that their prayers can never again be heard. ⇐

4. This is about the point where folks will come crawling out of the walls to tell stories about IBM or Rambus or Oracle or any of the codec sharks that have played the heel in standards at one point or another. Don't bother; I've got a pretty full file of those stories, and I can't repeat them here anyway. But if you do manage to blog one of them in an entertaining way without getting sued, please drop a line. ⇐

5. You know, in case you're wondering what CSS WG was doing from '04-'21. I wonder what changed? ⇐

6. It's particularly disingenuous for fifth columnists to claim proposals they don't like are "not standards track" as they know full-well that the reason they aren't being advanced within chartered working groups is their own opposition.

   The circularity is gobsmacking, but works often enough to reduce pressure on the fifth columnist by credulous web developers that it gets trotted out with regularity. Sadly, this is only possible because other vendors fail to call bullshit. Apple, e.g., would not be getting away with snuffing out the mobile web's chances were it not for a cozy set of fellow travellers at Mozilla and Google. ⇐

7. Most Web API design processes cannot claim any kinship to the scientific method, although we have tried mightily to open a larger space for testing of alternative hypotheses within the Chromium project over the past decade.

   Even so, much of the design work of APIs on the web platform is shaped by the specific and peculiar preferences of powerful individuals, many of whom are not and have never been working web developers. ⇐

8. Hiring "known quantities" to do the wrangling within a Working Group you want to scupper is generally cheaper than doing constructive design work, so putting in-group old-timers on the payroll is a reliable way for fifth columnists to appear aligned with the goals of the majority while working against them in practice. ⇐

9. One rhetorical mode for those working to constrain the web platform's capabilities is to attempt to conflate any additions with instability, and specifically, the threat that sites that work today will stop working tomorrow. This is misdirection, as stability for the ecosystem is not a function of standards debates, but rather the self-interested actions of each vendor in the market.

   When true browser competition is allowed, the largest disciplining force on vendor behaviour is incompatibility. Browsers that fail to load important web pages lose share to those that have better web compatibility. This is as close as you can get to an iron law of browser engineering, and every vendor knows that their own engine teams have spent gargantuan amounts of time and money to increase compatibility over the years.

   Put more succinctly, backwards compatibility on the web is not seriously at risk from capability expansions. Proposals that would imperil back compat¹¹ are viewed as non-starters in all web standards venues, and major schisms have formed over proposed, incompatible divergence, with the compatibility-minded winning nearly every skirmish.

   No SDO representatitive from these teams is ignorant of these facts, and so attempts to argue against solving important problems by invoking the spectre of "too much change, too fast" or "breaking the web" are sleights of hand.

   They know that most web developers value stability and don't understand these background facts, creating space for a shell game in which the threat of too much change serves to obsure their own attempts at sabatoge through inaction. Because web standards are voluntary and market share matters tremendously to every vendor, nothing that actually breaks the web will be allowed to ship. So armed, you can now call out this bait-and-switch wherever it appears. Doing so is important, as the power to muddy these waters stems from the relative ignorance of web developers. Educating them to the real power dynamics at work is our best bullwark against the fifth column. ⇐

10. There's no surer sign of the blindness many SDO participants exhibit toward the breakage of the voluntary implementation regime than that they extend deference on that basis to Apple.

    Fruit Co. engineers engaging in SDOs do not bear a heightened presumption to share when they will implment if others lead. To the contrary, they have so thoroughly lowered expectations that nobody expects even timely feedback on proposals, let alone a commitment to parity. Cupertino sullying the brands they force to carry WebKit's worst-of-the-worst implementation is simply accepted as the status quo.

    This is entirely backwards, and Apple's representatitives should, instead, be expected to provide implementation timlines for features shipped by other vendors. God knows they can afford it. Until such time as Fruit Co. relents and allows true global engine competition, it's the only expectation that is fair, and every Apple employee should feel the heat of shame every time they have to mutter "Apple does not comment on future product releases" while unjustly perpetuating a system that harms the entire web. ⇐

11. The browser and web infrastructure community have implemented large transitions away from some regretted technologies, but the care and discipline needed to do this without breaking the web is the stuff of legend. Big ones that others should write long histories of are the sunsetting of AppCache and the move away from unencrypted network connections.

    Both played out on the order of half a decade or more, took dozens of stakeholders to pull off, and were games of inches adding up to miles. New tools like The Reporting API, Deprecation Reports, and Reverse Origin Trials had to be invented to augment the "usual" tool bag of anonymised analytics trawls, developer outreach, new limits on unwanted behaviour, and nudging UI.

    In both cases (among many more small deprecations we have done over the years), the care taken ensured that only a small fraction of the ecosystem was impacted at any moment, lowering the temperature and allowing for an orderly transition to better technology. ⇐

12. Your correspondent has heard different stories from folks who had reason to know about the period from '08-'10 when Apple pulled its foot off the gas with Safari.

    Given the extreme compartmentalisation of Apple's teams, the strategic import of any decision, and the usual opacity of tech firms around funding levels ("headcount") to even relatively senior managers, this is both frustrating and expected.

    The earliest dating puts the death of the web as "Plan A" before Steve Jobs's announcement of the iPhone at Macworld in June 2007. The evidence offered for this view was that a bake off for system apps and the home screen launcher had already been lost by WebKit. Others suggest it wasn't until the success of the App Store in '09 and '10 that Apple began to pull away from the web as a top-tier platform. Either way, it was all over by early 2011 at the very latest.

    WebKit would never again be asked to compete as a primary mobile app platform, and skeletal funding for Safari ensured it would never be allowed to break out of the OS's strategic straightjacket the way IE 4-6 had. ⇐