Security rollouts need a route beyond the biggest platform

A security feature can be well designed and still reach few people if adopting it requires them to replace their working infrastructure. Starting on a widely used platform can be a reasonable allocation of scarce engineering time. The responsibility is to make that starting point explicit and give other platforms a credible route to support. Otherwise an adoption shortcut becomes a lasting condition of participation.

The November 2024 debate around PyPI attestations exposed this tension. Looking back from November 2026, the question worth retaining concerns rollout governance: who benefits first, who does extra work, and who is responsible for widening access? Those questions apply to internal company tools as well as public package registries.

A personal argument about engineering priorities

In his essay of 18 November 2024, William Woodruff argued for meeting maintainers on the services they already used. He explicitly presented personal opinions, rather than the position of his employer, PyPI or projects he participated in. That attribution matters: the essay is an engineer's argument, not an institutional guarantee of future support.

Woodruff distinguished the already wider set of Trusted Publishing providers from the initial GitHub-focused automatic attestation experience. He pointed to open standards, explained that new providers needed review of identity claims, and expressed intentions to widen support. Neither an open interface nor an intention establishes universal availability on that date.

His historical argument used package metadata links to show GitHub's prominence. Such links are evidence of association with a host, rather than a complete census of build systems. The priority argument does not need to turn that proxy into a precise measurement of every maintainer's publishing infrastructure.

Friction decides whether protection gets used

A proposed security improvement has an adoption cost even when nobody pays a licence fee. Someone must understand it, obtain access and maintain it after the original author moves on. If the safe path is embedded in a familiar release process, a maintainer can use it while doing the job they already intended to do.

For an illustrative business with several development teams, an access review could begin with the identity service most teams use. That first integration could remove repetitive account work for many people. Demanding support for every unusual system before any team benefits might postpone a useful control indefinitely. This is a design example, not a rollout performed by AL+.

The first deployment should nevertheless state its denominator. “Available to teams using this identity service” is assessable. “Available to the company” hides the teams still excluded. A leader needs both the number of eligible teams and the work required for the remainder before judging adoption. Successful use among eligible people does not prove company-wide coverage.

This changes the release conversation. Ask what work the integration removes, what the excluded teams must still do, and how support requests will be handled. Adoption becomes part of the engineering design rather than an instruction to users to care more about security.

Open interfaces reduce a barrier, not the whole cost

An open interface gives another platform something stable to implement against. It can reduce dependence on one vendor's private behaviour. It still leaves practical questions about identity, account separation and operations. Accepting a provider that cannot reliably distinguish one project from another would undermine the feature being extended.

Woodruff's account makes provider review part of the work. For a company planning a similar rollout, the appropriate lesson is to budget for integration assessment. Documentation should explain the required identity properties and who evaluates them. “Anyone can integrate” is misleading if acceptance actually needs an unstaffed review queue.

There is also work on the excluded side. A small platform may need engineering effort to emit the right claims, maintain compatibility and respond to failures. Publishing a specification does not supply that capacity. A credible extension path names which party does which work and what evidence demonstrates compatibility.

None of this requires identical implementation schedules. It requires reasons that a smaller participant can understand and challenge. Scale can justify an order of work without justifying permanent silence about everyone behind the first group.

The strongest objection is concentration that persists

The objection to a GitHub-first rollout is stronger than dislike of a popular vendor. Every convenient integration can make the dominant platform more convenient still. Users of alternatives may face pressure to migrate, even when their existing practices are responsible. Procurement rules can amplify that pressure by converting an optional feature into a pass-or-fail badge.

A rollout therefore needs language that separates unsupported from insecure. A missing integration can be an evidence gap under a particular policy. It does not, by itself, establish negligent maintenance. Keep a documented exception path while the extension work remains incomplete, with review proportional to the actual risk.

The counterargument has limits too. A project cannot review every tiny provider immediately, and some proposed integrations may impose costs that exceed their likely benefit. An accountable refusal can be legitimate. It should identify the missing requirements or operational burden rather than imply that the current dominant provider is the only acceptable home for software.

For your next custom software project, ask for the first supported population and the next integration decision in the same proposal. Name the person responsible for that decision, the criteria for adding another provider and the interim route for excluded users. Ship useful protection where it can work now, while keeping the boundary of that protection visible and contestable.