ExoCode
Introduction
By analogy with an exothermic physical process, an exovaloric social process is one that generates more value, utility, or benefit than the resources it consumes—often through cooperation or amplification. Since software development involves collaboration and value creation, we introduce ExoCode: an exovaloric process designed to create value through software production.
ExoCode draws inspiration from the C4.1 process(1) described in the ØMQ Guide(2), but targets smaller groups (around a dozen collaborators rather than hundreds). It aims to drastically reduce the number of rules while preserving the essence of what makes C4.1 successful.
Objective
ExoCode should:
- Preserve the most valuable aspects of the C4.1 process as described in the guide.
- Contain significantly fewer rules than C4.1.
- Be usable by a single developer.
- Be adoptable by a new developer in under an hour.
ExoCode
ExoCode is the process used by this project to update its code. When in doubt, refer to the C4.1 process(1).
Platform
The platform is where the code is hosted — e.g. github.com, codeberg.org.
Issue
An issue is created using the platform’s issue tracker. It consists of an assertion and a predicate that must be true for a patch to be considered a solution.
Patch
A patch is a Git commit containing data intended to be added to the project.
Valid patch
A valid patch:
- Solves one issue.
- Follows the project’s code style.
- Adheres to the Evolution of Public Contracts1.
- Uses the same license as the project.
- Is owned by its author; no copyright assignment required.
- Does not include non-trivial code from other projects unless the contributor is the original author.
- Compiles cleanly and passes project self-tests on all main target platforms.
- Contains a commit message composed of:
- An assertion as the first line.
- A blank line.
- An explanation of why the patch makes that assertion true.
- Does not break the master branch when merged.
Contributor
From a contributor’s point of view — i.e. someone who wishes to submit a patch to the project — the process is:
- Log in to the platform with your real name or well-known alias.
- Add or choose an issue to solve in the issue tracker.
- Fork the project.
- Build a patch that solves the issue.
- If you are not listed as a contributor, identify yourself.
- Submit a pull request.
- After the pull request is merged by a maintainer, close the issue.
Maintainer
From a maintainer’s point of view — i.e. someone who reviews and merges patches — the process is:
- Log in to the platform with your real name or well-known alias.
- Select a pull request.
- Verify that the patch is valid.
- If the patch is invalid, explain why to the author and:
- either return to step 3;
- or reject the pull request.
- If the patch is valid, merge it into the "master" branch.
Administrator
From an administrator’s point of view — i.e. someone who manages maintainers — the process is:
- Promote the most effective maintainers to administrators.
- Remove inactive maintainers.
- Ban "bad actors" after public discussion.
Founder
From a founder’s point of view — i.e. someone who created the project and/or is its moral owner — the process is:
- Act as an administrator.
Discussion
ExoCode has far fewer rules than the C4.1 process but refers to it in case of doubt. Experience will show whether it fulfills its goals. Most importantly, it requires at least one project and one entity — similar to iMatix as described in the Guide — to hold a trademark and enforce the license. Until then, it cannot be put to the test.
Conclusion
ExoCode may serve as a draft for a simpler C4.1 process but cannot surpass it unless adopted by a project with significant stakes.