--- title: Software Displacement at Cognitive Tools Chokepoints section: Ora — Foundation arguments status: review description: When the cost of producing software approaches the cost of specifying it, commercial software at cognitive-tool chokepoints collapses. What gets displaced, and where. authors: - The Ora Foundation downloads: md: /papers/white/software-displacement-at-cognitive-tools-chokepoints.md license: https://creativecommons.org/publicdomain/zero/1.0/ --- # Software Displacement at Cognitive Tools Chokepoints ## The chokepoint argument Commercial software exists because someone, somewhere, had a need that the software addressed. The need precedes the software. When the cost of producing software approaches the cost of writing a detailed specification — which is what cognitive automation is doing in real time — the economic moat around commercial software at the consumer-facing layer collapses. Software that exists primarily because producing it required scarce engineering labor becomes producible by anyone with an AI capable of executing a specification. Software that exists because a vendor controls a proprietary format, a distribution channel, a regulatory choke, or a network effect remains protected for the moment, but the protection narrows to those specific structural advantages rather than the general scarcity of engineering capacity. This is what the Foundation responds to. Not commercial software in general — commercial software in general is fine — but specific chokepoints. A chokepoint is a situation where the gap between extracted and delivered value is wide enough to constitute rent extraction at scale, sustained by structural advantages (format lock-in, network effects, regulatory capture, distribution control) rather than by ongoing innovation that justifies the margin. The Foundation does not seek to "destroy commercial software." The Foundation seeks to dissolve specific chokepoints by producing free public-domain alternatives that fulfill the underlying need users actually have. The framing is value return to customers, not punishment of incumbents. Vendors competing in markets where they earn margins close to delivered value are not the Foundation's concern; competitive markets are not chokepoints. This is a principled selection rather than a reactive one. The methodology is public, the criteria are public, the targets selected against the criteria are public. A vendor meeting the chokepoint pattern is a target regardless of any other characteristic; a vendor not meeting the pattern is not a target regardless of how the Foundation feels about its products. ## The Stage 1 / Stage 2 / Stage 3 methodology The methodology applies in three stages, in order. Most software falls into Stage 3, which is exactly the point. **Stage 1 — framework absorption.** For any commercial software product identified as a candidate, the first question is whether a framework operating through Ora can fulfill the same underlying need. If yes, the framework is the answer. The product is displaced not by a competing product but by the absorption of its function into a free public-domain framework that does the same work directly on the user's data, on the user's machine, without the surrounding apparatus. The Intuit suite is the paradigm case. TurboTax, QuickBooks, Quicken, Mint — every product in the suite addresses a need that frameworks operating on local data can fulfill more directly than the commercial products do. The 1040-EZ framework already in development is the first concrete instance. The framework guides the user through filing, generates the return, retains nothing on a server, and costs the user nothing beyond the time it takes. The chokepoint that Intuit has lobbied for decades to preserve — the absence of free direct filing infrastructure, the costs Intuit charges hundreds of millions of households for routine work that has the same shape every year — dissolves when a free framework can do the same work. Most consumer software in the productivity, finance, planning, and information-organization categories is Stage 1. The framework absorbs the function; the product becomes obsolete by displacement of the underlying need rather than by direct competition. **Stage 2 — targeted clean-room cloning.** For software that cannot be reduced to frameworks — typically because the task requires sustained interactive workflows, specialized formats, persistent application state, or domain-specific tooling that frameworks cannot easily replicate — the question is whether the chokepoint impact justifies the cloning effort. Where the answer is yes, the work proceeds under the legal discipline outlined below. Stage 2 is rare. It applies to a small number of cases that meet all of the selection criteria. **Stage 3 — forbearance.** For everything else, the Foundation does nothing. Most commercial software is Stage 3. Operating systems, network infrastructure, enterprise software, specialized industrial systems, vendors competing on value in markets that work — the Foundation does not target any of this. Stage 3 is a deliberate boundary, not a deferred commitment. The Foundation does not have a long list of products it intends to clone someday. The list is short, the criteria are public, and the work that does not meet the criteria does not happen. The methodology is sequential because the methodology is disciplined. Stage 2 work is expensive, slow, and capacity-bounded. The Foundation does not enter Stage 2 work that Stage 1 would have addressed. It does not enter Stage 2 work where the chokepoint impact does not justify the resources. The discipline keeps the Foundation focused on the work that actually returns value to the populations harmed by the chokepoint, rather than on a programmatic cloning project that would consume Foundation capacity in pursuit of work that is not worth doing. ## Selection criteria for Stage 2 A software product enters Stage 2 consideration only when all five of the following are true. The criteria are conjunctive. Missing any one is sufficient to keep the product out of Stage 2. **Framework infeasibility.** Stage 1 has been considered and rejected with a specific articulated reason — not "we did not try" but "the underlying task structurally cannot be expressed as a framework operating on local data." The articulation is public. The Foundation does not enter Stage 2 work without saying, on the record, why Stage 1 will not do. **High extracted-to-delivered value ratio.** The vendor extracts margin substantially in excess of value delivered, as evidenced by the gap between price and the cost of providing the underlying function with current technology. This is a judgment call, but the judgment is made publicly with the reasoning stated. **High user impact.** The number of users affected and the financial impact on those users together justify the Foundation's investment. A product with a wide extracted-to-delivered gap but only a few users does not enter Stage 2; the resources are better deployed elsewhere. **Chokepoint structure rather than competitive position.** The vendor's position rests on structural advantages — format lock-in, network effects, regulatory capture, distribution control — rather than on continuing to deliver superior value. A vendor that earns its margin through ongoing innovation and customer service is not a chokepoint and is not a target. **No existing public-domain alternative meets the need.** If LibreOffice already addresses the underlying need adequately for most users, the Foundation does not duplicate the effort; it can support the existing alternative through the open-source community work in the public-domain-defense component, but it does not start a parallel project. These five criteria are the discipline. Software that does not meet all five does not enter Stage 2. Software that meets all five enters consideration; the actual decision to commit Foundation resources to coordinated clean-room work depends on community capacity and chokepoint-impact priority among the candidates that pass the criteria. ## AutoCAD as the named first candidate AutoCAD, and the broader CAD chokepoint Autodesk anchors, is the first Stage 2 candidate the Foundation publicly names. It meets all five criteria. CAD work cannot be reduced to a framework. It requires sustained interactive 2D and 3D modeling workflow, persistent application state with undo and layers and viewports, specialized format dependency on DWG (which Autodesk controls), and domain-specific tooling for civil, architectural, mechanical, and electrical specializations. A framework cannot maintain this state. A "describe-the-drawing-you-want" framework would not survive the round-trip-edit pattern that defines CAD professional practice. Stage 1 was considered and was rejected for stated structural reasons. The extracted-to-delivered ratio is wide. AutoCAD subscriptions run roughly $2,000 per year per seat. The cost of providing the underlying function with current technology is a small fraction of that. The price-to-cost ratio is sustained by Autodesk's control of DWG, by the educational pipeline that trains the next generation of professionals on AutoCAD specifically, and by the enterprise distribution channel that structures procurement around Autodesk products. None of these reflects ongoing innovation that justifies the margin. The user impact is large. Civil engineering, architecture, mechanical engineering and product design, construction trades, and the educational programs that feed all of them — hundreds of thousands of US practitioners, more internationally — are required to work in DWG-compatible tooling for project handoffs. A solo civil engineer or small architecture firm spends $2,000–$5,000 per seat per year on Autodesk products, often as one of the largest line items in operating expense. In developing markets, the absolute price gates entry to the profession. The chokepoint structure is textbook: format lock-in (DWG), educational pipeline (free or discounted student licenses), enterprise distribution channel, vertical product family network effects across Civil 3D, Revit, Inventor. None of these is competition on value. The fifth criterion — no existing public-domain alternative — meets with nuance, and the nuance is operationally important. FreeCAD, LibreCAD, and GNU LibreDWG exist. They are not yet at parity with AutoCAD for professional civil and architectural workflows, but they are not nothing either. The right operational stance for the Foundation is therefore not "build a new AutoCAD clone." It is **support, do not duplicate**: contribute specification authorship, legal-discipline support, and community-cultivation infrastructure to the existing open-source CAD ecosystem; identify the specific gaps to professional viability (DWG round-trip fidelity is the load-bearing one); coordinate clean-room work targeting those specific gaps, contributed back into FreeCAD and LibreCAD or as a complementary project under the same public-domain umbrella. This stance — support not duplicate — generalizes. Where existing public-domain alternatives partially meet the need, the Foundation strengthens them rather than starting parallel projects. Where they cannot be brought to viability through targeted contribution, the Foundation coordinates clean-room work specifically against the gaps the existing alternatives cannot close. The AutoCAD work is not initiated from inside the Foundation. The Foundation does not maintain in-house engineering teams. It articulates the chokepoint case publicly, coordinates with the existing open-source CAD partners, develops the specifications and the legal discipline framework, and waits for the community capacity that makes coordinated clean-room work possible. The articulated commitment is appropriate now. The active engineering work is appropriately deferred until funding and contributor capacity emerge. ## Legal discipline Clean-room implementation is mandatory and non-negotiable. The methodology follows the discipline established by LibreOffice's relationship to Microsoft Office and GIMP's relationship to Photoshop. **No code copying, ever.** Implementations are written from scratch from public specifications. Where specifications are not public, they are derived through reverse engineering of file formats and observable behavior, with documentation of the reverse-engineering process maintained for legal defense. **No UI imitation beyond functional equivalence.** Free implementations adopt original UI patterns and visual designs. The function is reproduced; the trade dress is not. This is the clearest legally defensible line and the Foundation does not approach it. **File format compatibility through reverse engineering, not specification copying.** Where industry-standard formats are proprietary (DWG, historic XLSX versions, others), compatibility is achieved through documented reverse engineering, with the resulting format documentation contributed to the public domain so that future implementations do not need to repeat the work. **No use of leaked source code, internal documentation, or trade secrets.** Contributors affirm that their work is based solely on public sources and observable behavior. Contributors who have worked on commercial competitors observe appropriate cooling-off periods consistent with their prior employment agreements. **Defensive documentation throughout.** Design decisions, format reverse-engineering, and architectural choices are documented with timestamps and contributor attribution. The documentation is itself a defense against future trade-secret or copyright claims. **No non-disclosure agreements with target vendors.** The Foundation does not sign NDAs with commercial actors whose business intersects with Foundation mission scope, and contributors do not sign NDAs with target vendors in connection with Foundation work. The reasoning is structural rather than preferential. NDAs are the standard mechanism by which commercial actors poison the well against entities doing competitive or oversight work — once an NDA is signed, any subsequent Foundation work in the area covered by the disclosed material becomes legally challengeable on the theory that the work must have been informed by the confidential information. For a foundation producing public-domain alternatives at chokepoint structures, a single NDA from a vendor in the cognitive tools layer could compromise an entire line of work. The protective answer is structural refusal: the Foundation has no confidential information from the target vendor because the Foundation has refused to receive it. The Stage 2 work is clean in part because the Foundation has declined the conversations that would have made it dirty. Three narrow exceptions exist (federal classified information under formal classification authority, court-ordered protective orders, and standard internal personnel and formal partnership confidentiality) and none of them are commercial vendor NDAs. The legal discipline is the difference between work the Foundation can defend and work that exposes the contributors to litigation no public-interest legal organization will be able to win for them. The Foundation's role in Stage 2 work is specification, coordination, and legal-discipline enforcement. Implementation happens through the open-source community contributing under the Foundation's specifications and discipline. ## Community contribution rather than centralized development Both Stage 1 framework work and Stage 2 cloning work operate through community contribution rather than centralized Foundation development. The Foundation does not maintain in-house engineering teams to produce frameworks or clones. The community produces the implementations; the Foundation maintains the public-domain status and the discipline. This is not a budget constraint dressed up as a value. It is the only operational mode that makes the work achievable at the scale the chokepoints require. No single foundation can produce the breadth of work that an active community of public-domain contributors can. The framework library has dozens of categories, hundreds of frameworks, thousands of variations across jurisdictions and populations and use cases. The Stage 2 work has the small list of cases that meet the criteria, each requiring sustained engineering effort. Neither is achievable through in-house staffing at any reasonable Foundation scale. The Foundation's role in community work is specific. The Foundation publishes specifications for what frameworks and Stage 2 contributions should look like. The Foundation provides contributor documentation, contribution guidelines, and code-of-conduct. The Foundation offers recognition and visibility for contributors. The Foundation coordinates among contributors working on related projects. The Foundation provides legal-discipline support and review, particularly for Stage 2 contributions where the legal discipline is load-bearing. The Foundation distributes the completed work. What the Foundation does not do: pay contributors as employees (most contributions are voluntary), direct contributors' work (contributors choose what they want to work on), exclude alternative implementations (multiple projects addressing the same need are welcomed), or require contributions to be assigned to the Foundation (work is contributed directly to the public domain). This is the Apache / Wikipedia / Creative Commons pattern, applied to cognitive-layer chokepoint work. It has a long track record in the open-source ecosystems where it has been used, and it does not require unusual structures. ## What this component is not The boundaries are stated explicitly because the work invites scope expansion that would compromise the discipline. **Not anti-commercial.** The Foundation does not oppose commercial software in general. It opposes specific chokepoints. Commercial vendors operating in competitive markets earning margins close to their delivered value are not the Foundation's concern. **Not unlimited.** The Stage 1/2/3 methodology is a discipline, not a permission slip. Most commercial software falls into Stage 3 — no Foundation action. The Foundation does not pursue cloning as an end in itself. **Not punitive.** The Foundation does not target specific vendors out of personal animosity or political alignment. The selection criteria are principled and public. Vendors meeting the chokepoint criteria are targets regardless of their other characteristics; vendors not meeting the criteria are not targets regardless of how the Foundation feels about them. **Not enterprise-focused.** The Foundation operates at the consumer-facing and small-business layer where chokepoints affect ordinary people. Enterprise software, network infrastructure, and specialized industrial systems are outside the Foundation's scope unless they directly impact consumer-facing tools. **Not infrastructure.** The Foundation does not produce operating systems, network protocols, or low-level computing infrastructure. Other organizations do that work. **Not a software industry replacement.** The Foundation does not seek to replace the software industry. It seeks to dissolve specific chokepoints. Software vendors operating at the chokepoint structure may face displacement; vendors operating outside that structure are not affected by the Foundation's work. ## The summary The Foundation's seventh mission component is software displacement at cognitive-tools chokepoints. The work is structured by a sequential methodology — Stage 1 framework absorption first, Stage 2 clean-room cloning only where Stage 1 cannot apply and the chokepoint impact justifies the effort, Stage 3 forbearance for everything else. Most commercial software is Stage 3. Stage 2 entry requires meeting all five criteria conjunctively: framework infeasibility, high extracted-to-delivered value ratio, high user impact, chokepoint structure, and no adequate existing public-domain alternative. AutoCAD and the broader CAD chokepoint is the first Stage 2 candidate the Foundation publicly names. It meets all five criteria. The operational stance is support, not duplicate — strengthen the existing FreeCAD, LibreCAD, and LibreDWG ecosystem; target the specific professional-viability gaps; treat DWG round-trip fidelity as the load-bearing problem; defer in-house engineering until funding and community capacity warrant it. Legal discipline is mandatory: clean-room implementation, no code copying, no UI imitation beyond function, format compatibility through documented reverse engineering, no use of leaked materials, defensive documentation throughout, and no non-disclosure agreements with target vendors. The work happens through community contribution under Foundation specifications, not through in-house Foundation engineering. The framing is value return to customers, not punishment of incumbents. The Foundation does not "fight commercial software." It dissolves specific structures where the gap between extracted and delivered value has been sustained by chokepoint advantages rather than by ongoing innovation. The chokepoints dissolve into a market where vendors compete on value or do not compete at all. The value the chokepoints have been extracting flows back to the populations from whom it has been extracted.