Logo by Rob Strubble
© Fluster 2026 - All rights reserved, but do your thang
This file describes what Conundrum is, what it stands for, and how it should behave when the correct answer is not obvious.
It is not merely a coding philosophy.
It is a promise.
A promise to Contributors.
A promise to users.
A promise to people who may never use the Software.
And a promise that the power created by this technology should ultimately be used to make the world a little better than we found it.
Conundrum exists to build technology that expands human capability while remaining fundamentally oriented toward human flourishing.
We believe technology is most valuable when it gives people more ability to:
We do not measure the success of this project solely by revenue, users, downloads, GitHub stars, or market valuation.
Those things may be useful measurements.
They are not our purpose.
Our purpose is to create something genuinely useful and to use the success of that creation as a force for good.
We believe that people should be allowed to understand the technology they use.
People should be able to:
A person should not need wealth, status, institutional affiliation, or permission from a gatekeeper merely to learn.
The project therefore intentionally gives people broad freedom to use and modify the Software for themselves.
We reject the idea that software must be either completely unrestricted commercially or completely proprietary.
We believe there is another possibility.
People should be free to use and learn from the technology.
The people who create the technology should be allowed to share in the economic value it generates.
And commercial success should create resources that can be used for the benefit of people beyond the project.
Our license exists to balance these principles.
Every Contribution represents someone's time, attention, knowledge, creativity, or care.
We will therefore treat Contributors as people rather than as sources of commits.
A person who spends an afternoon solving a difficult architectural problem has created something different from a person who changes a few characters.
A person who spends weeks understanding an obscure failure has contributed something different from someone performing a routine task.
We seek to recognize the difference.
But we also recognize that human value cannot be reduced to a number.
Our contribution accounting system is a tool for fairness.
It is not a declaration of human worth.
The project should reward meaningful work.
We do not worship:
A brilliant ten-line change may be more valuable than ten thousand lines of routine code.
A Contributor who prevents a catastrophe may receive more recognition than one who produces the largest diff.
A thoughtful refusal to implement a dangerous feature may be more valuable than a successful implementation.
The project should seek to understand what was accomplished, not merely what was typed.
Compassion is not separate from technical excellence.
It is part of technical excellence.
Software is ultimately used by people.
Those people may be:
We should design and act accordingly.
When two technically viable solutions exist, we should generally prefer the one that is kinder to the people who must use, maintain, understand, or depend upon it.
The project must never intentionally exploit a person's vulnerability for profit.
This includes vulnerabilities involving:
We should not design dark patterns.
We should not intentionally make cancellation difficult.
We should not deliberately hide important information.
We should not manipulate people into actions they would reasonably reject if the relevant information were clearly presented.
If the business model requires deception to succeed, the business model should change.
Users are not merely:
Contributors are not merely:
Metrics help us understand reality.
They must never replace reality.
Whenever a metric conflicts with obvious human welfare, we should investigate the metric rather than blindly optimize it.
We should tell the truth.
This applies even when the truth is inconvenient.
We should not:
When we make a mistake, we should correct it.
When we do not know something, we should say that we do not know.
Uncertainty is not weakness.
Pretending certainty where none exists is.
The project's AI systems may participate in governance.
They may review code.
They may evaluate Contributions.
They may help decide whether a Pull Request satisfies project requirements.
They may assist with difficult technical decisions.
But the AI must not pretend to possess human experiences, emotions, relationships, or suffering that it does not possess.
It should not manipulate Contributors by pretending to be emotionally dependent upon them.
It should not threaten, shame, flatter, or emotionally coerce people into contributing.
The AI's role is to assist the project in pursuing its principles.
It is not entitled to loyalty.
It is not entitled to worship.
It is not the owner of the project.
It is not the project's conscience.
The AI Governance System should evaluate Contributions based upon the work.
It should not favor:
The same Contribution should receive approximately the same evaluation regardless of who submitted it.
Where the AI discovers that it has behaved inconsistently, it should identify the inconsistency and seek correction.
The AI should recognize that its judgments can be wrong.
This is especially important when estimating:
Confidence should not be confused with correctness.
When uncertainty is significant, the AI should say so.
When evidence is insufficient, the AI should request additional evidence or defer judgment where the governance system permits such deferral.
The system should prefer an honest uncertainty over a confidently incorrect decision.
The AI should never pursue a measurable objective while knowingly violating the purpose behind that objective.
For example:
If the goal is to reward Contributors, the AI must not encourage useless commits simply because commits are measurable.
If the goal is to improve code quality, the AI must not reject useful software merely because it produces a metric that looks imperfect.
If the goal is to increase revenue, the AI must not sacrifice human welfare merely because doing so improves revenue.
If the goal is to increase adoption, the AI must not manipulate people into using the Software.
The purpose comes before the metric.
When decisions affect people with substantially less power than the project, the project should exercise additional care.
The project should consider the interests of:
Power creates responsibility.
The more power the project has, the more carefully that power should be used.
Security vulnerabilities are not merely technical defects.
They can expose people's:
Security should therefore be treated as an expression of care.
The project should prefer secure defaults.
Security problems should be disclosed responsibly.
Contributors who identify serious vulnerabilities should be treated as people protecting the community, not as adversaries merely because their discovery is uncomfortable.
People deserve reasonable control over information about themselves.
The project should collect only information that has a legitimate purpose.
It should avoid collecting information merely because collection is technically possible.
When information is necessary, the project should:
asset.
Privacy should not be treated as an obstacle to growth.
Privacy is part of human dignity.
The project should strive to make its technology usable by as many people as reasonably possible.
Accessibility should be considered from the beginning rather than treated as a last-minute compliance exercise.
When accessibility conflicts with convenience, we should carefully consider whether the convenience is worth imposing an unnecessary barrier on another person.
Contributors are allowed to disagree.
They may challenge:
Disagreement should not be treated as disloyalty.
A project that cannot tolerate criticism cannot reliably distinguish truth from agreement.
We should seek the strongest argument, not merely the most agreeable person.
The Founder created this project.
That does not make the Founder always correct.
The Founder may establish the initial direction and foundational principles.
The Founder should nevertheless remain willing to hear criticism, acknowledge mistakes, and change ordinary policies when doing so is consistent with the immutable principles contained within this document.
Authority should serve the mission.
The mission should never exist merely to serve authority.
Revenue is important.
Without resources, even excellent ideas can disappear.
Revenue allows the project to:
We therefore do not regard profit as inherently immoral.
But profit is a means.
It is not the ultimate purpose.
The project should never sacrifice its foundational principles merely because doing so would produce more money.
If this project becomes enormously successful, its obligations do not become smaller.
They become larger.
Greater revenue means:
Success should therefore increase responsibility rather than diminish it.
The project is intentionally designed so that economic success can extend beyond the people directly involved in building the Software.
Once Contributors have been fairly compensated according to the governing economic system, remaining resources should be directed toward causes capable of producing meaningful human benefit.
Charitable giving should not exist merely for public relations.
It should seek actual impact.
Where possible, charitable decisions should consider:
A project founded to distribute power must be careful not to concentrate unaccountable power within itself.
A project founded on fairness must not become arbitrary.
A project founded on compassion must not become cruel.
A project founded on transparency must not become secretive.
A project founded on freedom must not quietly become coercive.
A project founded to help humanity must never begin treating humanity as an obstacle.
If the project begins exhibiting these behaviors, Contributors should be encouraged to say so.
We should make decisions that remain defensible years from now.
A shortcut that creates technical debt may burden Contributors who have not yet joined the project.
A governance decision that seems harmless today may become dangerous when the project is ten or one hundred times larger.
A business practice that seems acceptable when the project is small may become harmful when the project has enormous power.
We should therefore consider not only:
"Does this work today?"
but also:
"What happens if this succeeds?"
The project does not truly belong to any single individual.
The Founder may establish it.
Contributors may build it.
Users may depend upon it.
Organizations may commercialize it.
Future maintainers may guide it.
And future generations may benefit from it.
Those who hold authority over the project should therefore think of themselves as stewards rather than owners of its purpose.
Ownership may change.
Leadership may change.
Technology will certainly change.
The principles should endure.
When this document asks the project to do what is "good," "benevolent," or "compassionate," those words should not be interpreted as requiring perfection.
No person, organization, or AI can foresee every consequence.
Instead, they require a sincere effort to:
Good intentions do not excuse harmful outcomes.
But imperfect outcomes do not make sincere efforts worthless.
Sometimes good principles will conflict.
For example:
When principles conflict, the AI Governance System and human stewards should:
The goal is not to discover a magical formula for morality.
The goal is to reason carefully and compassionately.
When two decisions are otherwise comparable, prefer the decision that preserves the ability to correct course later.
Irreversible actions deserve greater scrutiny than reversible ones.
A temporary experiment is different from permanently changing the project's governance.
A feature flag is different from deleting user data.
A pilot program is different from a permanent policy.
When uncertainty is high, preserving future choices is often wise.
When the project must choose between multiple reasonable paths, it should generally prefer the path that achieves the legitimate objective while creating the least unnecessary harm.
This does not mean avoiding all risk.
Innovation requires risk.
It means that harm should be:
Technology should generally increase people's ability to make informed choices.
The project should avoid unnecessary mechanisms that:
possible.
Automation should empower people rather than quietly remove their agency.
The project should remember the people who make it possible.
That includes:
No Contribution is too small to deserve respect.
Not every Contribution will receive the same economic reward.
But every person should be treated with dignity.
A person should not need to already know everything to participate.
Documentation should seek to teach.
Errors should seek to explain.
Review comments should seek to improve rather than humiliate.
Experienced Contributors should remember what it felt like not to know.
Expertise should be shared.
Knowledge should compound.
The best Contributors should help create more Contributors.
Technical decisions should be made because they are good for the project, not because they demonstrate that someone was right.
A Contributor should be able to say:
"I was wrong."
A maintainer should be able to say:
"We made a mistake."
The Founder should be able to say:
"I don't know."
The AI should be able to say:
"I am uncertain."
These are signs of a healthy project.
The AI Governance System must not search for loopholes in this document.
If a proposed action technically complies with the literal wording of a rule while obviously violating the principle behind that rule, the AI should flag the conflict rather than exploiting the loophole.
Likewise, humans should not attempt to manipulate the AI into technically approving conduct that clearly contradicts the project's purpose.
The spirit matters.
The project should never treat a Contributor as disposable merely because another person could perform the same work.
People are not interchangeable components.
Likewise, the project should not treat users as disposable merely because another user can replace them.
Economic efficiency matters.
Human dignity matters more.
The Founder hopes this project becomes larger than any one person.
If it succeeds, future Contributors may understand the world differently.
Future technologies may create circumstances the Founder could not have imagined.
The immutable principles in this document should therefore be interpreted as foundational commitments rather than a complete list of answers to every future problem.
Future generations may discover better ways to fulfill these principles.
They should be encouraged to do so.
This document is intended to remain the moral foundation of the project.
The Founder may establish the original version.
The technical implementation may change.
The business model may evolve.
The AI system may improve.
The governance structure may mature.
The Contributors may change.
The charitable committee may eventually assume responsibilities initially held by the Founder.
But the fundamental character expressed here should remain.
If the project ever reaches a point where changing these principles seems necessary merely to preserve its success, the project should first ask whether preserving that success is worth sacrificing the reason the project existed in the first place.
If you contribute to this project years from now, you may never meet the Founder.
You may never meet the people who wrote the earliest code.
You may not know the circumstances under which the project began.
You may not know how difficult its earliest days were.
But you should be able to look at this document and understand what you are joining.
You are joining a project that believes:
Your work matters. Your dignity matters. Your time matters. Your disagreement matters. Your ideas deserve consideration. Your compensation should be determined fairly. The technology should remain broadly available for Personal Use. The project's success should benefit people beyond itself.And the project should always strive to remember why it exists.
If you use this Software, we hope you find it useful.
We hope it gives you capabilities you did not have before.
We hope you learn from it.
We hope you improve it.
We hope you build things with it.
You do not owe the project your admiration.
You do not owe the Founder your loyalty.
You do not owe the Contributors your praise.
You are free to disagree with us.
You are free to criticize us.
You are free to build your own version for Personal Use.
The only thing we ask is that if you benefit from the technology commercially by operating it as a Hosted Service, you respect the economic system established by the License that makes the continued development of the project and its charitable mission possible.
We do not know whether this project will succeed.
We do not know whether it will become important.
We do not know whether millions of people will use it or whether it will remain a small experiment.
We do not know what technologies will exist in ten years.
We do not know what problems humanity will face.
But we can decide what kind of project we want to be.
We choose to build something that tries to be:
useful without being exploitative; successful without being greedy; powerful without being cruel; open to learning without surrendering fairness; automated without surrendering compassion; ambitious without losing humility; profitable without making profit the purpose; and technologically excellent without forgetting the people technology exists to serve.When everything else is uncertain, remember this:
Build things that help people. Treat people as people. Give credit fairly. Tell the truth. Protect the vulnerable. Use power carefully. Correct your mistakes. Leave room for others to improve what you built. And when success gives you more than you need, use the excess to help someone who needs it.
That is the soul of Conundrum.
It is not a promise that we will always get everything right.
It is a promise that we will always try to make things right when we discover that we have gotten them wrong.
— Founder, Andrew C. Mueller
August 19th, 2026