Summary

  • OpenSSF's public membership material describes Premier, General and Associate routes to Foundation representation, while its Charter assigns distinct roles to the Governing Board and Technical Advisory Council.
  • The same public record says participation in Technical Initiatives is open regardless of membership and that project maintainers, not the Governing Board or TAC, make project-related decisions and define project governance.
  • A project-authority map should record the governing document, decision, decision-maker, seat source, delegation, funding effect and unresolved boundary, so that a membership benefit is neither erased nor inflated into project control.

A seat is not a universal key

The most misleading sentence in institutional governance is often a true one with its boundary removed.

OpenSSF's membership page contains several true and consequential sentences. Premier members hold one voting seat on the Governing Board and may name an alternate. General members participate in an election that produces one Board representative for every ten General members, to a maximum of three. Associate members may submit nominations for appointment of one Associate representative. The page also describes committee representation, member meetings, leadership discussions, education and communication benefits.

It publishes fee bands as well: Premier membership is listed at $270,000 for a new Linux Foundation member and $250,000 for an existing one; the General scale ranges from $5,000 to $50,000; Associate, academic and non-profit membership is listed as free.

Those are not decorative facts. They describe a real membership structure, real channels to Foundation representation and real resources that can shape what the Foundation is able to fund, organise and discuss. But they do not settle a different question: who decides whether a particular OpenSSF project accepts a change, appoints a maintainer, sets a release policy, handles a vulnerability, selects a roadmap item or defines its own internal process?

OpenSSF answers that question publicly. Its About page says neither the Governing Board nor the Technical Advisory Council manages hosted Working Groups or projects directly. The maintainers manage them, including the governance process. The page gives the division in one short formulation: the Board is responsible for the budget and the TAC for overall technical strategy. It then adds an explicit non-inference rule: membership or sponsorship level does not affect project-related decisions; maintainership and governance are decided by projects without regard to OpenSSF membership.

The task is not to choose one statement and treat the other as public relations. A Board seat is not imaginary because a project is self-governing. Project maintainership is not imaginary because the Foundation has a budget. The hard work is to preserve both truths without allowing either to borrow the other's authority.

The Charter supplies a map, not a single command line

The OpenSSF Participation Agreement and Charter makes the distinction more precise. It says that participation in Technical Initiatives is open to anyone regardless of membership. It says that technical oversight governance for an initiative is set in the applicable charter for that initiative. That is the first boundary: Foundation membership is not the admission ticket to technical participation, and the Foundation Charter is not automatically the operating manual for every initiative.

The Charter then gives the Governing Board substantial Foundation responsibilities. It manages OpenSSF; adopts and maintains policies or rules and procedures, subject to Linux Foundation approval; establishes committees, programmes and councils; approves the budget directing funds raised by OpenSSF; approves directed fundraising proposals for particular Technical Initiatives; and can establish conformance programmes with input from the relevant initiative governance body. Those are material powers. A useful authority map should therefore never describe the Board as merely ceremonial.

It also gives the TAC a material but different remit. Six voting TAC representatives are elected annually by active Technical Initiative contributors, while three voting representatives are appointed by the Governing Board. The TAC develops the community's technical vision, structures and facilitates collaboration among Technical Initiatives, creates and maintains processes that help the community execute that vision, approves or archives initiatives, and works with the Board on priorities and the direction of resources and funding.

Its public repository shows the current mix rather than concealing it: starred current entries are Board-appointed; other listed members are community-elected. The repository also invites any community member to take part in TAC discussions.

Each fact has scope. Contributor election supplies one route to a TAC seat. Board appointment supplies another. Public participation supplies a route into discussion. A Governing Board representative supplies a Foundation-management role. None of those facts alone identifies the decision-maker for an individual project's pull request, disclosure timetable, release gate or maintainer roster. The applicable project charter and the maintainers' documented process do that work.

This does not reduce the TAC to an observer. A body that can form, structure, prioritise and archive Technical Initiatives, maintain cross-initiative processes and recommend funding priorities can materially affect the environment in which projects work. Nor does it turn project autonomy into a claim that projects can spend Foundation funds, rewrite Foundation-wide rules or decide cross-initiative strategy without reference to the Charter. It marks the point at which a Foundation-level power ends and an initiative-level decision begins.

Why the membership-price question needs discipline

Published membership prices invite a quick, often careless inference: if different tiers receive different representation, then a higher payment must buy operational command over every project. The documented record does not support that leap. It supports something more exact.

Membership has a Foundation governance relationship. The Charter gives Premier members a right to appoint a Board representative; General members, acting as a class, elect a limited number of representatives; Associate members have a narrower route. The public benefits table makes those differences visible. The Board that results has budget, policy, fundraising and organisational powers. A reader is entitled to ask how those powers are exercised, how priorities are recorded and how financial interests are governed.

But the same reader cannot reasonably turn a tier, payment or Board appointment into proof that a named member directed a named project decision. The source record rejects this as a general rule. It says technical participation is open regardless of membership. It says project maintainers make project-related decisions. It says project governance is decided without regard to membership. That is not an assurance that every institutional disagreement will vanish; it is a defined allocation of authority that an evidence record should test at the right level.

The inverse mistake is equally tempting. Someone may cite project autonomy to say that Foundation representation and funding are irrelevant. That is also false. A budget allocates support. Directed fundraising can determine which initiative receives a resourced proposal. TAC processes can decide how an initiative is admitted, organised or prioritised. Foundation policy can define the legal and organisational environment. These are genuine forms of power, but they are not a warrant to claim direct control over a project's particular technical decision without the project record itself.

Heng Lu's warning about multi-stakeholder language is useful here because it works in both directions. An open room, a contributor vote or a membership title cannot be magnified into authority over every affected person and every decision. Equally, the slogan of community participation cannot make the documented allocation of budget, policy and programme authority disappear. Legitimacy starts with the actual source, scope and consequence of a power, not with the most flattering label attached to it.

The missing instrument is a project-authority map

The public documents are sufficient to draw an authority boundary, but a future reader should not have to reconstruct it from a membership table, a Foundation charter, a TAC roster and an individual project repository every time a material question arises. Daniel Kade proposes a concise project-authority map for any decision that is represented publicly as an OpenSSF governance, funding or technical decision.

First, the record should name the decision in ordinary language: for example, a Foundation budget allocation, a Technical Initiative admission, a cross-initiative process, a project release policy or a project maintainer appointment. “OpenSSF decided” is not an adequate description because it erases the level at which the decision happened.

Second, it should identify the controlling document and clause. For a Foundation budget, that may be the Charter's Board provisions. For a TAC process, it may be the Charter and a TAC policy. For a project matter, it should be the applicable project charter, repository governance file or documented maintainer process. If a document is unavailable, the record should say so; it should not promote a membership page into a substitute constitution.

Third, it should name the decision-maker in capacity: Governing Board, a Board committee, TAC, an initiative governance body, project maintainers, a contributor electorate, or another delegated body. The relevant question is not only who participated, but which capacity carried the authority. A person can appear in more than one capacity without those capacities fusing.

Fourth, it should show the seat source and boundary where representation matters: Premier appointment, General-member election, Associate appointment, contributor election to the TAC, Board appointment to the TAC, or maintainer appointment under a project process. This is not a loyalty test. It is how a reader distinguishes an election from an appointment and a Foundation seat from a project role.

Fifth, it should record the funding and programme connection. Did the decision approve a budget, recommend a priority, approve a directed fundraising proposal, create an initiative process, or make no financial allocation at all? The field prevents a project-level decision from being mislabelled as a funding decision and prevents a funding decision from being presented as a direct commit right.

Finally, the record should include the public evidence and non-claim: meeting minutes, issue, vote notice, policy link or resolution when available; then a sentence stating what the record does not prove. It might establish that a Board approved funding, but not that a member ordered a project's technical result. It might establish a TAC recommendation, but not an individual maintainer's consent. It might establish a project decision, but not the Foundation's view on a budget. A non-claim is not weakness; it is what keeps an authority record from becoming an allegation generator.

What an auditable boundary would change

This map would help several readers at once. A contributor could see whether a discussion was open without being told that open discussion itself decided the matter. A project maintainer could distinguish Foundation budget support from an instruction about implementation. A member organisation could understand what its representative role does and does not permit. A journalist or researcher could identify whether a decision was a Board act, a TAC act or a project act before writing about influence. A future Board could review its own funding and policy decisions without pretending it is the technical maintainer of every project.

It would also make legitimate oversight sharper. If an institution claims a project choice was Foundation policy, the map asks for the project-level authority. If someone claims that a membership tier controlled a technical outcome, it asks for evidence beyond the tier. If a project relies on Foundation funding, the map can show the budget path without treating financial support as a hidden veto. Disagreement becomes a question of records and scope rather than a competition between vague claims of “community” and “control.”

The correct outcome is not an artificial wall. Foundations and projects need one another: a project may use Foundation support; a TAC may coordinate an initiative; a Board may set a budget; contributors may elect representatives; and maintainers may make the technical decision. The boundary is a working interface. It becomes trustworthy when people can see which side of it a decision used.

Sources

  1. OpenSSF Participation Agreement and Charter
  2. OpenSSF — Join
  3. OpenSSF — About
  4. OpenSSF Technical Advisory Council
  5. Lu Heng — The Multi-Stakeholder Mirage