Governance

A standard is only worth as much as the process behind it. This page describes that process honestly, including the parts that aren't yet good.

Current state, stated plainly

This is a benevolent-dictator project on day one. Rohith Reddy Gopu founded it, wrote the first framework, and currently merges everything. That's the correct structure for a project with one contributor and the wrong structure for a standard, so the rest of this page is about how it stops being true.

Pretending otherwise on launch day would be its own kind of dishonesty.

The commitments

These four are the ones that make this different from a vendor's content marketing, and they're meant to be held to.

1. The framework is permanently free and openly licensed. Content under CC BY 4.0, code under MIT. Fork it, sell training on it, build a product against it, use it in your internal ladder. Attribution is the only requirement. There will never be a paid tier of the definition.

2. No single company owns the standard. Not Palantir's, not any AI lab's, not any employer of any maintainer, including Rohith's. Maintainers disclose their employer. No employer gets a veto or a private channel.

3. Changes happen in public. Every framework change is a pull request with a rationale. Every accepted change is in the changelog with attribution. Disagreement is preserved in the thread rather than tidied away — the argument history is part of what makes it a standard.

4. Maintainership is earned by contribution, not appointed by relationship. When someone has made repeated substantive contributions, they get commit rights. This is how it works in every open-source project that lasted, and there's no reason to invent something new.

How the framework changes

Patch (0.1.x) — wording, typos, clarifying an ambiguous cell without changing its meaning. One maintainer approval.

Minor (0.x.0) — changing what a cell means, adding signals, revising a level summary. Two maintainer approvals and a seven-day comment window.

Major (x.0.0) — adding or removing an axis, changing the number of levels. Public proposal, thirty-day comment window, and a documented rationale that addresses the objections raised rather than noting them.

Versions are semantic so an organization can say "we level against FDE Framework 0.1" and have that mean something stable.

How to disagree

The framework lives at content/framework/framework.yaml.

• Small correction — pull request, straight at the file.
• Substantive disagreement — open an issue with the framework-feedback template. Cite the axis and level, describe the situation where the cell is wrong, and say what you would replace it with. "This is wrong" isn't actionable; "this cell reads ambiguously in a leveling conversation, here's the case" is.
• Not a Git user — open an issue in plain prose. Someone will land it and you keep the attribution. The barrier to improving a standard shouldn't be tooling fluency.

What happens next

The honest roadmap, in order:

1. Now — single maintainer, open contribution, no formal structure.
2. At around five regular contributors — a maintainers file, written merge rules, two-approval rule active for minor changes.
3. At around three active chapters — a chapter council with real authority over events, the playbook, and the ambassador programme.
4. If and when it matters — a neutral legal home so the standard doesn't depend on one person's continued interest or goodwill.

Step 4 exists because a commons that depends on one person isn't a commons yet. It's a project that people are being generous about.

Conflicts of interest

Maintainers disclose their employer publicly. A maintainer doesn't merge a change that materially advantages their employer without a second approval from someone elsewhere. If the FDE Community ever takes sponsorship, sponsors get named on a page and nothing else — no roadmap input, no framework input, no private channel. That's written down here before there's any money, deliberately, because it's much harder to write afterwards.