Key Takeaways

  • Restrictive software licenses fail when coding agents can ingest a codebase and translate it into a different programming language overnight.
  • Cohen built NanoClaw over a 40-hour weekend, released it under an MIT license, and built NanoCo around the resulting enterprise inbound.
  • Less than one percent of companies build internal agent tooling directly on open-source repos; the remaining 99 percent pay for hosted security, compliance, and container sandboxing.
  • Distribution and community trust form the real defense for developer tools because competitors can copy your repository, but they cannot fork your credibility.
  • Maintainers should govern repo bloat using Cohen's Code Contribution Evaluation Formula to reject low-utility changes with large code footprints.

Cohen's Code Contribution Evaluation Formula

Maintainers must decide which contributions belong in core software and which belong on external branches. Cohen evaluates upstream pull requests by balancing user value against codebase weight:

Component 1: Utility

The functional utility that the contribution adds to the codebase.

Component 2: Target Market

How broad or universal the audience is that benefits from the contribution (avoiding super niche fixes).

Component 3: Lines of Code

The total number of lines of code introduced by the change, placed in the denominator.

The operational calculation is simple: maximize (Utility * Target Market) / Lines of Code. If a change requires 500 lines of code for three users, it belongs on a custom fork rather than upstream.

When This Works (and When It Doesn't)

Cohen built NanoClaw as a fast 40-hour weekend build before it took off. In developer tools, open distribution generates early adoption, but pull requests quickly pile up. Maintainers who merge every feature end up drowning in technical debt and breaking existing users. Applying this formula protects the core architecture while keeping the binary light and maintainable. It works best for libraries, agent frameworks, and developer utilities where codebase size directly degrades reliability.

The formula stumbles when applied to mission-critical bugs or security patches. A security patch might change 400 lines of code to fix an edge case affecting only five enterprise clients. By raw formula scoring, you would reject the pull request. Yet failing to patch an exploit destroys the exact trust that Cohen points to as the project moat. Use the ratio for feature requests and integrations, not for security vulnerabilities or protocol compliance.

What to Do With This

Open your GitHub repository's pending pull requests this morning. Pick the three oldest open contributions. For each pull request, assign a score of 1 to 5 for functional utility and estimate the percentage of your active users who will touch it. Divide that product by the total lines of code added in the diff.

If a pull request introduces 600 lines of Python to support a database driver used by two community members, close the pull request with a polite note. Point the contributor to your plugin architecture or suggest they maintain the feature in a community fork. Reserve upstream merges strictly for changes that score high on universal utility with minimal code additions.