Two Windows, Two Rulesets
Microsoft's winget package manager, launched in May 2020 as part of the Windows Package Manager project on GitHub, and the Microsoft Store are both distribution channels for free and open-source software on Windows — but they operate under meaningfully different conditions, and conflating them costs maintainers time.
winget is community-governed in practice: packages enter the winget-pkgs repository through pull requests that supply a manifest — a YAML file declaring the package identifier, version, installer URL, and licence. Microsoft publishes a validation policy for that repository; submissions must include a valid SPDX licence identifier or a licence URL, and the installer must be downloadable from a stable URL and pass automated checks, including malware and SmartScreen scans. Code-signing is not strictly mandated, but unsigned installers are more likely to trigger warnings or fail validation, and a package whose upstream changes its release pipeline in this way may be blocked from updates until the problem is resolved. For small maintainers, acquiring and renewing an Extended Validation certificate — the tier that avoids Windows SmartScreen warnings — carries a recurring cost that no winget policy offsets.
The Microsoft Store's conditions are heavier. Packages distributed through the Store must comply with Microsoft's Store Policies, a separately versioned document that governs content, behaviour, and update cadence. Free software listed in the Store is subject to the same content policies as commercial software. Critically, the Store controls the update pathway: an app may not use its own updater to push a newer version outside the Store's delivery mechanism once it is listed there. For projects that ship their own auto-update infrastructure — Electron-based tools being the common case — this creates a fork in the distribution logic that must be maintained deliberately, not accidentally.
Licence changes complicate both channels. winget manifests record a licence field, but the repository's policy does not specify an automated process for removing a package when an upstream project relicences to a non-open-source or source-available licence. In practice, removal has been handled through community-filed issues on a case-by-case basis. The Store's policies are silent on open-source definitions entirely; Microsoft's Store review team evaluates submissions against its own content and safety criteria, not the Open Source Definition maintained by the Open Source Initiative.
Neither channel offers the reproducibility guarantees that projects like Reproducible Builds formalise: winget fetches and runs whatever binary the manifest points to, and the Store re-packages or re-signs artefacts in ways that can alter what a user installs relative to what the maintainer built. For maintainers who care about provenance, that gap matters as much as the signing requirement.