Many Eyes, Fast Cycles
Open-source communities solve hard problems by distributing review and collapsing the distance between use, critique, and change.
Open-source communities solve hard problems by collapsing the distance between use, critique, and change. Openness is not a substitute for review — and it is not a licence to extract from maintainers.
Software can be inspected, forked, and patched. A community of users is also a community of reviewers. Reputation, licences, and maintainers form a governance layer as real as any org chart.
Linux, and the culture around it, showed that distributed scrutiny can outpace closed review — not because everyone is an expert, but because the people closest to a failure can see it and propose a change.
HACKERS studies distributed scrutiny. Also: burnout of maintainers, supply-chain trust, and the myth that ‘open’ means ‘safe’. Companies that take more than they return hollow out the method.
The edge case is often found by someone you did not hire, standing in a place you did not model. That only works if they can read, patch, and be heard — and if someone is funded to receive the patch.
This is not a licensing story. It is a scrutiny-protocol story.
Software can be inspected, forked, and patched. A community of users is also a community of reviewers. Reputation, licences, and maintainers form a governance layer.
Transparency is a quality instrument. It is not a halo.
Closed teams treat review as a bottleneck only staff can perform. That is sometimes true for secrets. It is often an excuse for not wanting to be read.
The right to read, modify, and share, plus a social protocol for accepting change, is the method. Without the protocol you have a dump. Without funding you have a tragedy of the unpaid.
Openness does not mean the code is correct. It means the chance of being seen is higher — if anyone is looking, and if looking is survivable for the people who maintain.
Name the false object, then drop it.
C1
Open means safe
A licence was treated as an audit.
Open means inspectable. Inspection is work. Work needs eyes and time.
C2
Many eyes is automatic
The proverb did the labour.
Eyes must be able to run, read, and be heard. Most never look.
C3
Maintainers are infinite
Idle expertise treated as a commons to strip-mine.
Maintenance is a job. Fund it.
C4
Fork is governance
Exit treated as voice.
A fork is a last resort. A receiving function for patches is governance.
C5
Supply chain is someone else
Dependencies treated as weather.
You run what you pull. Review it as untrusted.
What actually sat on the table.
Serious systems must be built by a closed team. Review is a bottleneck that only staff can perform.
Visible source → unexpected contributors → faster defect discovery → shared infrastructure. That chain is real. So is the other one: fame without funds, a hero maintainer, a supply chain that confused a licence with an audit.
HACKERS will not romanticise a commons while it is being strip-mined. We will ask who is on call, and who pays them.
Do not study the outfit.
A public GitHub org is a costume. So is a licence badge. The interesting object is whether a patch from the person in the failure would land this month.
If the case study stops at ‘many eyes’, you have a proverb. The studio begins when receive is a job.
Linux, and the culture around it, showed that distributed scrutiny can outpace closed review — not because everyone is an expert, but because the people closest to a failure can see it and propose a change.
Closed, staff review
Limited eyes. Honest about it.
Public dump, no protocol
Looks open. Dead.
Famous, unfunded
The failure cell for labour.
Inspectable, funded receive
Distributed scrutiny as a system.
S0 Closed product
open 20 / seen 40
S1 Source dump
open 70 / seen 25
S2 Protocol exists
open 60 / seen 65
S3 Near-failure eyes
open 55 / seen 80
S4 Unfunded fame
open 90 / seen 35
S5 Funded receive
open 70 / seen 92
Scrutiny with a job attached.
O1
Read is a right
You cannot scrutinise what you cannot inspect.
O2
Near is an instrument
The person standing in the failure sees first.
O3
Protocol over dump
A social path to accept change is the product.
O4
Fund receive
Eyes that cannot land a patch are decoration.
O5
Open ≠ trusted
Dependencies remain untrusted artefacts. Review them.
P1 Inspect
Can it be read and run?
Binaries as destiny.
P2 Propose
Can a stranger send a change?
A GitHub that never merges.
P3 Receive
Is someone funded to look?
Volunteer burnout as infrastructure.
P4 Depend
Do you treat what you pull as untrusted?
A supply chain of assumed goodness.
| ID | Failure | What broke | Control |
|---|---|---|---|
| F1 | Halo licence | MIT was treated as an audit. | Schedule review. Licences are not eyes. |
| F2 | Dump without protocol | Source posted, patches ignored. | A receiving path with SLAs. |
| F3 | Extraction | Firms take, never fund. | Pay maintainers of what you run. |
| F4 | Hero maintainer | One exhausted human as a chokepoint. | Redundant receive. Holidays that do not halt the commons. |
| F5 | Dependency weather | npm install as fate. | Pin, review, and be able to read what you run. |
| F6 | Open washing | A public repo for a product that cannot be changed. | If propose cannot land, do not call it open. |
Science
Methods that can be rerun.
Publication without replication is a source dump.
Wikipedia
Many eyes plus a talk page.
The protocol is the product. Vandalism is why receive matters.
City planning
The people in the failure proposing a change.
Without a receiving function, consultation is theatre.
File SEC-02
A fact needs an inbox.
Distributed scrutiny still needs a receiving function.
The right to read, modify, and share, plus a social protocol for accepting change. Transparency is a quality instrument.
Visible source → unexpected contributors → faster defect discovery → shared infrastructure. Also: burnout of maintainers, supply-chain trust, and the myth that ‘open’ means ‘safe’.
01 Make it readable
You cannot scrutinise a sealed box.
02 Make propose possible
A stranger can send a change without a theatre of access.
03 Fund receive
Pay the people who look. Holidays allowed.
04 Review dependencies
Treat pulled code as untrusted. Pin what you run.
05 Kill the halo
Do not skip audits because the licence is pretty.
06 Return value
If you take, you fund. Extraction is a defect.
- Only staff may review.
- Users are tickets.
- Dependencies are weather.
- Open is a halo.
- Maintainers are hobbies.
- The nearest failure can propose.
- A protocol receives the change.
- Dependencies are untrusted artefacts.
- Open is inspectable, not blessed.
- Receive is a funded job.
R0 Failure
Someone hits a bug in the field.
R1 Sight
Can they read the system they run?
R2 Voice
Can they propose a change?
R3 Receive
Does a funded human look?
R4 Commons
The next user inherits the patch — or the burnout.
R5 Industry
A supply chain that assumed open meant safe.
| Topic | Typical brief | HACKERS studio |
|---|---|---|
| Software engineering | Git as a tool. | Git as a scrutiny protocol with labour attached. |
| Security | Many-eyes proverb. | Who is looking, paid, and allowed to land a patch? |
| Economics | Public goods as a tragedy. | Fund receive. Extraction is a choice. |
| Org design | Inner source as a fad. | Can the person who suffers the failure patch it? |
| Ethics | Licences. | Labour of maintenance is the ethical object. |
Elite programmes still stop at the object.
Computer science still teaches open source as a licence lecture and a git tutorial. Economics still teaches public goods as a cartoon. Security still quotes Raymond without asking who is on call.
HACKERS trains the protocol and the labour. SCAN who may read. FLIP ‘open means safe’. BUILD a receiving path. BREAK it by removing the hero maintainer. PROVE funding, not a sticker.
Communities can be extractive. Companies that take more than they return hollow out the method. Openness is not a substitute for security review.
Do not admire the turning point. Redesign the join.
Which part of your closed process would get stronger if the people who suffer its failures could patch it?
Which part of your closed process would get stronger if the people who suffer its failures could patch it?
List the dependencies you run but cannot read. That list is a risk register.
Name the maintainer you profit from. What did you return this quarter?
Design receive so a holiday does not halt the commons.
Write a policy: open is inspectable, never a substitute for review.
Can the person in the failure inspect the system?
If not, many eyes is a speech.
0–8h
Map
What you run, what you can read, who you extract from.
8–20h
Protocol
How a stranger’s patch would land.
20–36h
Fund
A receive budget. A holiday plan.
36–48h
Depend
Untrusted-artefact review for one critical pull. Present labour, not a badge.
- Quote many eyes and skip the audit.
- Publish source you will never merge into.
- Build a company on an unpaid maintainer.
- Treat npm install as providence.
- Call a fork the governance model of first resort.
The edge case is often found by someone you did not hire, standing in a place you did not model.
Fund maintenance. Review dependencies as untrusted. Keep the ability to read the system you run.
- Is open source automatically more secure?
- No. It is more inspectable. Inspection is labour. Labour needs funding and a protocol.
- What is the HACKERS objection to ‘many eyes’?
- It is treated as a force of nature. It is a system: read, propose, receive, fund.
- Should companies always open the code?
- Not always. They should always be able to read what they run, and they should fund what they take.
- How does this link to File SEC-02?
- Both are receiving functions. One for vulnerabilities, one for patches. Both fail as theatre.
- What about supply-chain attacks?
- Open does not equal trusted. Review dependencies as untrusted artefacts. That is in scope. Recipes are not.
Cited for classification and method. Not as a manual. Atlas cases are educational and defensive.