The economics of open source¶
The programme's second wing reads the sovereignty problem through the economics of open source: who adopts it, what decides the adoption, and whether buyers will pool demand to fund it (the demand side); and who captures value around it and who encloses (the supply side). Both sides rest on the theory of FLOSS projects and open-source business models of Jullien, Viseur and Zimmermann (2025), which locates a project's value creation in the maintained flow rather than in the free code stock, together with the adopter typology that theory carries from von Hippel (2001) and the authors' own earlier work; one survey, in preparation, will feed the demand-side papers. Every formal proposition in the thread carries a numerical check in the projects' verification suites.
Value Capture in Commercial Open Source¶
On the supply side, most accounts of commercial open source are written about its loudest slice: venture-backed product vendors relicensing to fend off hyperscalers. This paper starts from the service majority: the firms selling assurance, adaptation, and assistance (the 3A services) around code they help maintain and do not own. It develops the axis that separates the two populations: the firm's funding path, formalized as patience in a two-period model. Contribution to the underlying project rises with the square of patience. Enclosure (relicensing away from open source) pays only for impatient, conversion-rich firms below a unique patience threshold. A community able to fork shrinks the region where enclosure pays; eroding service margins and project maturity widen it. The visible relicensings arrived after both conditions had taken hold. Status: a conceptual synthesis with a verified formal core (v0.4, which absorbed the formerly separate enclosure model); every proposition carries a proof, a numeric cross-check, and a Monte-Carlo robustness report, and the empirical test is specified as a survey design that has not been run. Companion explainer: The other ninety percent.
Buyers' Clubs for the Open-Source Flow¶
European supervisors ask firms and public buyers to pool procurement and co-fund open-source alternatives; the demand-pooling paper models the institution that proposal implies. The code stock is free; the club funds the flow (maintenance, security, evolution, compliance evidence) and contracts the excludable assurance, adaptation, and assistance services around it. Two open-source margins reshape the classic pooling problem. Members can pay dues in code as well as cash, so free-riding persists only in small, high-friction clubs and scale converts riders into contributing members; and license reciprocity returns riders' adaptations upstream, so copyleft partially self-finances the club. A public anchor buyer of computable size eliminates the everyone-waits equilibrium. Equilibrium membership is inefficiently low with an exact wedge. Against the voluntary-provision benchmark, the club's strict contribution is exactly the population priced out of self-provision. Operating steward bodies (OS2 in Denmark, IMIO in Wallonia) instantiate the mechanics, and the dissolved cases (Malta, Iceland) match the predicted failure mode. Status: theory with a fully verified suite (v0.4; eight propositions, each with a proof, a numeric cross-check, and a Monte-Carlo robustness run). The empirical design the paper carries awaits the shared open-source poll, and no result is estimated. Companion explainer: The club that pays in code.
Adopting Open Source in 2026¶
The demand side's design paper adapts UTAUT, the workhorse of technology-acceptance research, to organizational open-source adoption. It replaces the representative user with the value-network typology: adopters segmented by whether they can specify and develop (Innovative), specify only (Frontier), or neither (No-skill). Three open-source constructs (community support, transparency and auditability, strategic alignment carrying sovereignty) and two 2026 moderators (regulatory perceived risk under the CRA and AI Act, mitigated by commercial assurance) complete the model; the central hypothesis is that driver weights differ across capability segments. The design ships complete: instrument with item provenance, capability classifier with a behavioral validation, computed power analysis with its limits stated, and pre-registered tests. Status: the survey's registered design; no data have been collected and no coefficient is estimated. It re-enters the submission track when the poll delivers. Companion explainer: Who adopts open source? Ask who the adopter is.
Why Driver Weights Differ¶
The methods companion: in a random-utility adoption model where capability is a unit implementation cost, every driver weight a survey estimates is a product of structural sensitivity and the group's location on its adoption curve, so cross-group level comparisons confound the two. In the paper's Monte Carlo they misorder the capability ranking on 63 percent of sampled configurations under a probit link and 46 percent under a logit link, and cross-group comparisons of standardized coefficients reverse a true ordering on 17 percent. Within-group ratios of driver weights are free of the confound and identify the capability ordering on all of them; the survey's analysis plan adopts the resulting rules wholesale. Status: a verified methods paper (every claim carries a proof and a machine-precision cross-check, and no empirical claim is made); a documented sweep found partial antecedents for its ingredients, and the next revision repositions the contribution against that record. Companion explainer: The comparison that flips.