The third essay in eric-raymond's trilogy collected in the O'Reilly "Cathedral and the Bazaar" volume (1999), alongside cathedral-and-the-bazaar-1997 and homesteading-the-noosphere-1998. "The Magic Cauldron" addressed the question that methodological and sociological arguments leave open: how does open source software get funded?
Argument
Raymond catalogued nine economic models that support FOSS development, organized around the distinction between "use value" and "sale value" of software. His central argument: most software has high use value (to those running it) but low sale value (because distribution is near-free). This means commercial logic tends to support open sourcing more than intuition suggests.
The nine funding models Raymond identified (approximate, as of 1999):
1. Loss-leader or market-position models (give away software to sell hardware or services) 2. Widget-frosting (software supports sale of physical products) 3. Give away the recipe, open a restaurant (open source the code, sell customization/support) 4. Accessorize (open source enables accessories market) 5. Free the future, sell the present (open source old versions, sell current) 6. Free software, sell the brand (certification, distributions) 7. Free software, sell updates (subscription/maintenance) 8. Free software, funded by donations or grants 9. Consortium-funded development
Significance to the Movement
The essay represented the movement's attempt to answer corporate skepticism during the open-source-schism-and-dotcom-1998-2004 era. The question "how do you make money?" was the most common challenge to open source adoption, and Raymond's framework gave advocates a vocabulary for responding.
The models Raymond described anticipated much of the subsequent decade: the open-core-business-model evolved from his "give away the recipe" model, and the "sell support" model became the foundation of Red Hat's successful business. The essay also anticipated the tensions that would later produce the sspl-bsl — what happens when a cloud provider deploys your open source code as a service, capturing its use value without contributing back?
From the software-freedom-vs-open-source perspective, the essay is squarely in the pragmatic-open-source tradition: it treats software primarily as an economic good and asks how the economics can support open development. Stallman's tradition would ask whether these models adequately protect four-freedoms for users — a question Raymond treats as secondary.
The maintainer-sustainability-crisis of the modern-foss-and-sustainability-crisis-2015-present era suggests Raymond's models, while useful, missed the structural problem of distributed maintenance labor for infrastructure code that has no obvious owner or sponsor.