← Governance

The Honest Mission

Build software that keeps state out of code, and create open materials that let other developers do the same.

That sentence is the mission. Everything in this project, every line of code, every page of documentation, every certification awarded, every governance decision, must be in service of it. If a proposed action does not advance the mission, the project does not take the action — regardless of how worthy the action may be in its own right.

Why this mission exists

Software has been getting more stateful, more coupled, more opaque, and more fragile for decades. The dominant paradigm of object-oriented programming has produced codebases that hide state inside classes, scatter mutation across methods, and require enormous mental overhead to reason about. The arrival of AI coding assistants has accelerated this pattern: AI generates code that defaults to the median of its training data, and the median of its training data is class-based, mutable, and stateful.

There is an alternative. Pure functions, immutable data, declarative interfaces, state at the boundaries, composition over inheritance. These ideas are not new. They are the original ideas of computer science, recovered and made practical for the AI era. The Honest project exists to make them the default again.

The mission has two halves.

The first half — build software that keeps state out of code — is the practical work. The Honest Framework, Honest Builder, and the components that depend on them. The code itself, written to demonstrate that the principles produce better software in measurable ways: faster development, fewer defects, lower cognitive load, smaller teams shipping more.

The second half — create open materials that let other developers do the same — is the teaching work. The Honest Code book, the audit methodology, the curriculum, the certification, the governance documents, the public examples, the academic papers. The materials that let any developer anywhere learn the principles and apply them to their own work, without needing permission or paying tribute.

Both halves are required. Code without teaching is a private hobby. Teaching without code is empty doctrine. The mission is to do both, and to do them in the open.

What the mission is not

The mission is not to make money, although the Honest Code book and Honest Builder are commercial products and their revenue funds the rest of the work.

The mission is not to be popular, although becoming widely adopted would advance the practical and teaching halves of the mission.

The mission is not to be inclusive in the sense that current OSS governance discourse uses the word, although the project welcomes contributions from anyone who wants to advance the mission.

The mission is not to be a community in the sense of providing social belonging, although a working community of practitioners is necessary infrastructure for the mission.

The mission is not to advance any political, religious, or philosophical position beyond what is necessary to defend the technical principles. The Honest project has positions on classes, on hidden state, on declarative versus imperative interfaces, on the value of pure functions, on the failure modes of AI-assisted development. It does not have positions on anything else, and it does not take enforcement actions on any other basis.

The mission is not to provide a credential that signals membership in a community. The Certified Honest Practitioner credential exists to attest to demonstrated competence in applying the methodology. It is not a membership card.

Why narrowness matters

A narrow mission is the most important defense against scope creep, capture, and drift. If the project’s purpose is everything, the project’s purpose is nothing, and any working group can claim that any action is “in service of the mission” because the mission is defined broadly enough to permit any interpretation.

The Honest mission is one sentence, on purpose. It can be quoted in full at the start of any meeting, included in any decision document, and applied as a test to any proposed action. The test is: does this advance keeping state out of code, or does it advance creating open materials to let other developers do the same? If the answer is no, the action is not part of the project, regardless of how worthy it may be.

This narrowness is the load-bearing protection against the most common failure mode of open-source governance: scope expansion that turns the mission test into a tautology. A project that defines its mission as “build software and be a welcoming community and advance social inclusion and support marginalized groups and model healthy collaboration practices” has surrendered the mission test, because anything can be claimed to advance one of those goals. A project that defines its mission as “build software that keeps state out of code, and create open materials that let other developers do the same” has a test that cannot be argued around.

Who decides what advances the mission

The original author (Adam Zachary Wasserman) decides during his lifetime, with input from the project’s contributors and from the Foundation that holds the trademark. After his lifetime, decisions are made by the governance structure defined in the Constitution, which is bound to interpret the mission as written and cannot expand it.

The mission cannot be amended, expanded, or reinterpreted without the consent of the trademark holder, and the trademark holder is constitutionally bound to refuse any amendment that broadens the mission or weakens its narrowness.

Citation and reference

This document is referenced from:

Any document that cites the mission cites the sentence at the top of this file exactly, without abbreviation or paraphrase. The sentence is the canonical form. Everything else in this document is commentary on it.

The mission is the first thing and the last thing. Everything else serves it.