Current state. Ora can be forked from Git and modified manually today. The Ora Knowledge Foundation is not incorporated and is not accepting donations. Foundation submission, specification, review, reconciliation, recognition, testing, and distribution systems described below are intended future infrastructure, not current services. The earlier seven-component proposal and the separate provisional Passion/Operation model remain unresolved.
Why fork ecosystems matter
Public-domain release without an active fork ecosystem risks remaining theory. The dedication can be real on paper while the practical ecosystem remains small. If no one modifies, redistributes, or builds independently from the substrate, the alternative is legally permitted but not yet demonstrated in practice.
Active forking is the hoped-for way to make the dedication operative. The substrate is one option; independent modifications are other options; an ecosystem of alternatives would make the public-domain commitment visible in practice. A user who can adapt the architecture to an unanticipated need keeps more leverage with the user.
The proposed fork ecosystem is therefore more than a permission structure. It is a design goal for keeping the architecture adaptable to needs the original maintainers did not anticipate.
What forking has been
Forking, in conventional open-source contexts, has been the programmer’s privilege.
Modifying a codebase requires programming skill. The license says anyone can fork; the practical truth is that forking requires the ability to read, understand, modify, build, and maintain code. Most users do not have those skills. The result is that even projects with permissive licenses tend to centralize in practice. Users consume whatever the core maintainers ship, not because they could not modify it, but because modifying it requires capabilities they do not have.
This pattern has shaped what open source actually does. The communities that thrive in conventional open source are programming communities. The contributions that flow back into canonical projects are programming contributions. The voices that shape what an open-source project becomes are the voices of programmers who can demonstrate their judgment by writing code. Domain expertise that is not also programming expertise is largely outside this loop. A clinician with deep knowledge of medical conversation, a legal aid attorney who knows what benefits applications actually require, a teacher who understands what scaffolding their students actually need — none of them can contribute through the conventional contribution channel even when their judgment about what the software should do is better than the contributing programmers’.
The conventional fork ecosystem also has a recognizable life cycle. A canonical project gets popular. A faction disagrees with direction. The faction forks. The fork either stays small and dies, or grows enough to compete with the canonical version, in which case the disagreement gets argued out by which fork attracts more users and contributors. Forks happen, but they happen at the level of project-scale disagreement, not at the level of individual users tailoring the software to their work. The latter, in conventional open source, mostly does not happen.
What forking is in Ora
Ora inverts the contribution model.
The frameworks — the substantive cognitive content of the system — are written in natural language, not code. The harness, written in code, executes whatever framework is invoked against whatever input is provided. This makes framework modification a plausible path for domain experts, though each fork still needs its own evaluation.
Modifying a framework requires domain expertise, not programming skill. A legal aid attorney can modify a benefits-application framework because she knows what the form requires. A clinician can modify a medical-information-synthesis framework because he knows what clinical conversation actually looks like. A teacher can modify a learning-support framework because they know what their students need. The contribution barrier inverts: the populations that conventional open source largely excludes from contribution become the populations whose contribution is most operationally valuable, because they are the populations who know what the framework should do.
This is what “natural language is the source code” means as a structural claim rather than as a slogan. The source of the cognitive work is the specification of the cognitive work, and the specification is the framework, and the framework is what the contributor produces. The harness that executes the framework is infrastructure; the framework is what the substantive work runs as.
Forking could, in this architecture, become more than a project-scale event. A clinician could adapt a medical framework, an advocacy organization could add state-specific benefits variants, and a teacher could calibrate learning support. These are examples of intended use, not evidence that a Foundation contribution ecosystem already exists.
The operational guide for current repository forking is FORKING.md. It describes the current source-install and manual-modification path.
The reconciliation loop
Forks do not have to fragment the corpus. A future Foundation library could define a reconciliation pattern, but no Foundation-managed reconciliation facility is available to ordinary forkers today.
If a future Foundation creates a library and submission process, a fork that benefits broader users could be submitted against published specifications. Review, acceptance, attribution, testing, and distribution would be future institutional mechanisms. Independent forks remain public-domain possibilities without Foundation approval.
Two specific commitments make the reconciliation loop work without becoming gatekeeping.
Multiple frameworks for the same task can coexist. A future library need not be exclusive. A user who prefers a contributor’s variant can use it without leaving the broader public-domain ecosystem, whether or not a future catalog accepts it.
A future canonical library need not gatekeep alternatives. Forks, modifications, and independent collections can exist without Foundation involvement. Any future Foundation catalog would be one option, not the authoritative version.
The intended flow runs in both directions: a future library could be a substrate, independent forks could add alternatives, and accepted additions could return to a shared catalog. Apache, Wikipedia, and Creative Commons provide relevant precedents, but they do not guarantee that Ora will produce the same outcome.
Governance through specification publication
The proposed Foundation would publish specifications because publication could make a future contribution model legible.
A contributor who wanted to add a framework to a future library would read its specification and submit against it. The specification could be the contract; review and acceptance would be future mechanisms, not current services.
This design could distribute governance by separating substantive authorship from specification review. A future Foundation could maintain a standard, while material outside any future catalog remains a public-domain artifact others can use.
Specifications themselves could evolve through contributor feedback. Specification authorship is a proposed future Foundation function, not an operating service today.
This design would distribute cultural power that might otherwise concentrate in Foundation staff. The current Ora project does not claim a Foundation specification or review service.
What contributors get
The conventional question about non-monetary contribution models is what motivates contributors to do the work. The answer in this case has the same shape as the answer in successful prior fork ecosystems, with one specific addition.
Recognition. A future library could preserve contributor authorship and attribution. No Foundation recognition system currently operates.
Distribution. A future canonical library could distribute accepted material, but no Foundation distribution channel is promised. Today, a contributor can publish or share a fork independently.
The satisfaction of doing the work the population needs done. This is the addition that the natural-language contribution model surfaces specifically. The conventional open-source model offers programmers the satisfaction of building software they think is useful; the people who would benefit from the software are downstream of the building. The natural-language contribution model offers domain experts the satisfaction of building cognitive scaffolding they know is useful, for populations they already know, in domains where they have already been doing the work. The contribution is a continuation of the work the contributor has been doing, made available to a wider population. For many domain experts, this is not an abstract motivation — it is the work they have wanted to make available and have not had a distribution channel for.
No Foundation payment or recognition system exists. A future contribution model might be voluntary and could learn from Wikipedia, Apache, and Creative Commons, but those precedents do not guarantee the same result here.
Honest limits
Forking does not eliminate the need for review. A framework that a contributor produces is the contributor’s judgment about what the framework should do; that judgment can be wrong, partial, or calibrated to a population other than the population a downstream user is actually serving. Users who deploy contributor frameworks are still responsible for evaluating whether the framework is right for their use. A future library could expose documentation, test cases, and version history to help users understand what a framework was designed to do; it could not absolve users of judgment about whether the framework fits their case.
Contributors still need to know what good looks like. The natural-language contribution model lowers the barrier to producing frameworks; it does not lower the bar for what a good framework requires. A legal aid attorney can author a framework because she knows benefits law; a person who does not know benefits law cannot produce a competent benefits framework just because the contribution barrier is natural-language rather than code. Domain expertise is still domain expertise. A future specification standard could make some of that bar visible if a contribution system is established.
Specification standards would be a real bar. A future compliance check could be light by design while the specification itself encoded expectations about format, structure, documentation, testing, and provenance that take real work to meet. The bar would be the published specification, not discretionary institutional approval. No such Foundation specification or compliance check currently exists.
The fork ecosystem also assumes that users have the means to evaluate what they are forking. A user fork is a user judgment. Any future catalog could expose identity, documentation, tests, version history, and alternatives, but the Foundation does not currently certify framework quality or operate a contribution mechanism.
The summary
Public-domain release without an active fork ecosystem risks remaining theory. A living fork ecosystem is the intended way to make the dedication operative.
What forking has been: the programmer’s privilege, requiring code-level skill, with most users excluded from contribution and most projects centralizing in practice despite permissive licensing. What forking is in Ora: a contribution model where modifying the substantive content requires domain expertise rather than programming skill, where the populations that know what their populations need are also the populations that can produce the cognitive scaffolding their populations need, and where forks are routine user-scale events rather than rare project-scale ones.
The proposed reconciliation loop would keep a future shared catalog coherent without centralizing the whole ecosystem. Submission, review, recognition, testing, and distribution remain future infrastructure; alternatives would not require Foundation approval.
What future contributors might get is recognition, distribution, and the satisfaction of doing useful work. The natural-language contribution model makes that possibility visible; it does not promise a Foundation service today.
Honest limits remain. Forking does not eliminate review. Contributors still need to know what good looks like. Specification standards are a real bar. Users still have to evaluate what they fork. None of these limits is the architecture’s failure; all of them are what makes the architecture honest about what it does and does not do.
This paper draws lessons from Apache, Wikipedia, and Creative Commons while applying a proposed domain-expertise contribution model to cognitive frameworks. Those precedents inform the design; they do not guarantee Ora’s outcome.