The Ora Knowledge Foundation is an initiative in formation. It is not incorporated and is not accepting donations. This paper proposes a possible software-displacement program and its safeguards; the Foundation does not currently operate such a program, select targets, coordinate contributors, publish program specifications, conduct legal review, or maintain partnerships with software projects.

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 the kind of problem a future Foundation program could address. 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 proposal does not seek to “destroy commercial software.” Its aim would be to dissolve specific chokepoints through free public-domain alternatives that fulfill the underlying need users actually have. The framing is value return to customers, not punishment of incumbents. Competitive markets where vendors earn margins close to delivered value would fall outside the program.

The proposed selection method is principled rather than reactive. If the program were created, its methodology, criteria, reasoning, and selected work would be public. A vendor meeting the chokepoint pattern could be considered regardless of other characteristics; a vendor not meeting the pattern would remain outside the program.

The Stage 1 / Stage 2 / Stage 3 methodology

The proposed methodology would apply in three stages, in order. Most software would fall into Stage 3, which is exactly the point.

Stage 1 — framework absorption. For any commercial software product considered as a candidate, the first question would be whether a framework operating through Ora could fulfill the same underlying need. If so, the framework would be the preferred answer: displacement through a free public-domain specification operating on the user’s data rather than a competing product.

The Intuit suite is the paradigm case. TurboTax, QuickBooks, Quicken, and Mint address needs that local-data frameworks might fulfill more directly. A tax-filing framework is proposed as a concrete exploration, but no such Ora or Foundation framework is currently published. Any future implementation would have to be validated against current tax law and forms and should avoid retaining user data on a remote Foundation service.

The proposal places many productivity, finance, planning, and information-organization cases in Stage 1. A successful framework could absorb the relevant function and reduce the need for a competing product.

Stage 2 — targeted clean-room implementation. 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 would be whether the chokepoint impact justified the effort. Any future work would have to follow the legal discipline outlined below.

Stage 2 is intended to be rare and would apply only to cases that met every selection criterion.

Stage 3 — forbearance. Everything else would receive no program action. Most commercial software belongs in Stage 3. Operating systems, network infrastructure, enterprise software, specialized industrial systems, and vendors competing on value in functioning markets would remain outside the proposal. Stage 3 is intended as a deliberate boundary rather than a deferred commitment.

The methodology is sequential because Stage 2 work would be expensive, slow, and capacity-bounded. A future program would not enter Stage 2 when Stage 1 could address the need or when the chokepoint impact did not justify the resources. This discipline is intended to prevent a generalized cloning project from consuming capacity without returning commensurate value.

Selection criteria for Stage 2

A software product would enter Stage 2 consideration only when all five of the following were true. The criteria are conjunctive; missing any one would keep the product out of Stage 2.

Framework infeasibility. Stage 1 would have to be considered and rejected for a specific published reason — not “we did not try” but “the underlying task structurally cannot be expressed as a framework operating on local data.” A future program would not enter Stage 2 without stating why Stage 1 would not do.

High extracted-to-delivered value ratio. The vendor would have to extract 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. The judgment and its reasoning would be published.

High user impact. The number of users affected and the financial impact on those users together would have to justify any future investment. A product with a wide extracted-to-delivered gap but only a few users would not enter Stage 2; limited resources would be better deployed elsewhere.

Chokepoint structure rather than competitive position. The vendor’s position would have to rest on structural advantages — format lock-in, network effects, regulatory capture, or distribution control — rather than continuing to deliver superior value. A vendor earning its margin through ongoing innovation and service would not qualify.

No existing public-domain alternative meets the need. If an existing project already addressed the underlying need adequately for most users, the proposed program would not duplicate it. Future support for an existing alternative would require an actual relationship and capacity; none is implied here.

These five criteria define the proposed discipline. Software that did not meet all five would not enter Stage 2. Meeting all five would allow consideration, not commit resources; any later decision would depend on legal review, organizational capacity, contributors, and relative impact.

AutoCAD as the named first candidate

AutoCAD, and the broader CAD chokepoint Autodesk anchors, is the first case this paper evaluates under the proposed Stage 2 criteria. Naming it here does not mean that the Foundation has selected or begun a project.

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. This paper therefore rejects Stage 1 for the 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 — requires nuance. FreeCAD, LibreCAD, and GNU LibreDWG exist. They are not yet at parity with AutoCAD for all professional civil and architectural workflows, but they are substantial projects. The proposed stance is therefore support, do not duplicate: if relationships and capacity were established, a future Foundation could help articulate specifications, legal discipline, and gaps to professional viability rather than start a competing product. DWG round-trip fidelity is one likely focus. No such partnership or coordinated work currently exists.

This stance — support rather than duplicate — generalizes. Where existing public-domain alternatives partially meet a need, any future program should first explore whether invited, mutually agreed support could strengthen them. Only after that assessment should it consider independent clean-room work against gaps that existing alternatives cannot close.

No AutoCAD-related Foundation work has been initiated. The design does not assume an in-house engineering team. If the Foundation is incorporated and later adopts this program, it could publish the chokepoint case, seek consent-based relationships with existing open-source CAD projects, develop specifications and legal safeguards, and proceed only when qualified capacity exists. Active engineering is not a current commitment.

Any future clean-room implementation would require mandatory legal safeguards. The proposed methodology draws general lessons from independent compatible software projects; it does not claim that the Foundation has obtained legal review or that the cited projects endorse this proposal.

No code copying, ever. Implementations would be written from scratch using public specifications. Where specifications were not public, any reverse engineering of file formats or observable behavior would have to be documented and legally reviewed.

No UI imitation beyond functional equivalence. Future implementations would use original interface patterns and visual designs. The function could be reproduced; trade dress would not be copied.

No use of leaked source code, internal documentation, or trade secrets. Future contributors would have to affirm that their work was based solely on public sources and observable behavior. Contributors with relevant prior employment would have to observe their agreements and obtain appropriate legal guidance.

Defensive documentation throughout. Design decisions, format research, and architectural choices would be documented with timestamps and contributor attribution. That record could help demonstrate independent development in a later dispute.

No non-disclosure agreements with a target vendor for program work. If the Foundation operated this program, it would not accept target-vendor confidential information relevant to a clean-room effort, and contributors would not use such information in Foundation work. Receiving it could compromise the independence of later implementation. A future, legally reviewed policy could recognize narrow categories that do not authorize target-vendor contamination: formally classified federal information received under proper classification authority, disclosures governed by a court-ordered protective order, and ordinary confidentiality required for internal personnel matters or formal partnerships unrelated to the clean-room target. Their scope and safeguards would require counsel, governance approval, and later authorization before any program began. No NDA policy or exception currently operates.

Legal discipline would be the difference between defensible work and work that needlessly exposes contributors. Under the proposal, a future Foundation could provide specifications, coordination, and safeguards while implementation remained community-led. This is a design, not a claim that legal support, contributor terms, review, or enforcement capacity exists.

Community contribution rather than centralized development

Both Stage 1 and Stage 2 are proposed as community-contribution models rather than centralized Foundation development. The Foundation initiative has no in-house engineering team or active contributor program. If this work begins, independent contributors would produce implementations while the Foundation could steward public-domain and process commitments.

This is not a budget constraint dressed up as a value. It is the only proposed operating mode that could make work at this scale achievable. No single foundation could produce the breadth of work that an active community of public-domain contributors could. A mature framework library might span dozens of categories, hundreds of frameworks, and thousands of jurisdictional or use-case variations; even a small number of Stage 2 efforts would require sustained engineering. Neither ambition would be realistic through in-house staffing alone.

The Foundation’s possible future role is specific: publish specifications; provide contributor documentation, guidelines, and a code of conduct; recognize contributors; coordinate related work; establish qualified legal review for Stage 2; and distribute completed public-domain work. None of those systems or services currently operates.

The proposed model would not assume paid Foundation employment, direct volunteers’ work, exclude alternative implementations, or require copyright assignment to the Foundation. Exact contributor terms would have to be published before any intake opened.

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 proposal is not

The boundaries are stated explicitly because the work invites scope expansion that would compromise the discipline.

Not anti-commercial. The proposal does not oppose commercial software in general. It addresses specific chokepoints; vendors operating in competitive markets and earning margins close to delivered value would remain outside its scope.

Not unlimited. The Stage 1/2/3 methodology is a discipline, not a permission slip. Most commercial software would fall into Stage 3 — no program action. Cloning would not be an end in itself.

Not punitive. A future program would not select vendors out of personal animosity or political alignment. Its criteria and reasoning would be public, and work would be evaluated against them consistently.

Not enterprise-focused. The proposal concerns the consumer-facing and small-business layer where chokepoints affect ordinary people. Enterprise software, network infrastructure, and specialized industrial systems would generally remain outside its scope.

Not infrastructure. The proposal does not call for producing operating systems, network protocols, or low-level computing infrastructure. Other organizations already do that work.

Not a software industry replacement. The proposal does not seek to replace the software industry. It is limited to specific chokepoints; vendors operating outside those structures are not its subject.

The summary

This paper proposes software displacement at cognitive-tools chokepoints as one possible area of future Foundation work. Its sequential methodology is Stage 1 framework absorption first, Stage 2 clean-room implementation only where Stage 1 cannot apply and the impact justifies the effort, and Stage 3 forbearance for everything else. Most commercial software would be Stage 3. Stage 2 consideration would require meeting all five criteria together: 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 case evaluated in this paper. The proposed stance is support, not duplicate: explore invited support for FreeCAD, LibreCAD, and LibreDWG; identify professional-viability gaps; and treat DWG round-trip fidelity as a likely central problem. This analysis does not establish a partnership, select a project, or begin engineering work.

Any future work would require legal discipline: clean-room implementation, no code copying, original interface design, documented reverse engineering, no use of leaked materials, defensive documentation, and safeguards against target-vendor confidential information. The intended model is community contribution under public specifications, not in-house Foundation engineering. It has not been implemented.

The framing is value return to customers, not punishment of incumbents. If ever adopted, the program would address only structures where a persistent gap between extracted and delivered value is sustained by chokepoint advantages rather than ongoing innovation. Its aspiration would be a market in which vendors compete on value and the benefits of lower-cost tools flow back to users.