How to Not Build Most of It

Abstract
A Practical Guide: Get 500 Years of Clinical Research in 20, Avoid the Apocalypse, and Make Humanity Filthy Rich by Giving Papers
Keywords

war-on-disease, 1-percent-treaty, medical-research, public-health, peace-dividend, decentralized-trials, dfda, dih, victory-bonds, health-economics, cost-benefit-analysis, clinical-trials, drug-development, regulatory-reform, military-spending, peace-economics, decentralized-governance, wishocracy, blockchain-governance, impact-investing

The infrastructure for a decentralized framework for drug assessment (dFDA) won’t cost billions to build. Because you’re not building most of it.

Here’s the plan:

  1. Build the foundation (core API)
  2. Pay bounties for critical features that nobody wants to build yet
  3. Let everyone else build everything else for free

This is how WordPress, Linux, and every successful platform works. You build the rails, not every train.

The Core Strategy (How WordPress Beat Expensive Software)

The most successful software platforms don’t build every feature. That would be slow and expensive.

Instead, they build the foundation and let others build on top.

The Model

  • Build the Rails: Core infrastructure, APIs, data standards
  • Not Every Destination: Developers (companies, academics, individual humans with too much time) build specialized tools

Why This Works (Evidence Not Theory)

WordPress

  • Core software: Free and open-source
  • Community-built on top: Multi-billion dollar economy of themes and plugins
  • Result: Powers 43% of all websites
  • They didn’t build 43% of the internet. They built the foundation. Others built on it.

Linux

  • The kernel: Small core team
  • Everything else: Thousands of companies and individuals
  • Result: Runs most of the internet, all Android phones, world’s fastest supercomputers
  • Core team is tiny. Network of contributors is massive.

Browser Extensions

  • Chrome/Firefox: Provide APIs
  • Community: Creates extensions
  • Result: 188,000+ Chrome extensions
  • Google didn’t build them. Developers did. Because the platform made it profitable or useful.

Why Humans Do This For Free

Incentives align:

  • Commercial developers: Build businesses selling plugins
  • Academics: Build research tools, get papers published
  • Individual contributors: Build reputation, solve their own problems, impress other nerds

Everyone wins. Platform scales without the core team building everything.

Bounties and Prizes (Paying for Results Not Promises)

While an open platform mostly builds itself, sometimes you need specific features that nobody’s building yet.

That’s where bounties come in.

The “Right to Trial & FDA Upgrade Act” mandates a public bounty and prize program. Not grants (pay people who promise to build). Bounties (pay people who actually built it).

You don’t get papers for proposals. You get papers for code that works.

What Bounties Fund

Critical Features: Essential tools nobody’s building. Pay someone to build it. Problem solved.

Security Reporting: Bug bounty program. Pay hackers to find security flaws and report them instead of exploiting them. Cheaper than getting hacked.

High-Value Integrations: Connectors to major EHR systems, national health registries. Benefits everyone but nobody wants to build first. Bounties solve this.

Major Prizes: Big money for big achievements. Want a critical component? Offer $1M to whoever builds it best. Competition drives innovation.

The Difference

Grants: “Here’s money. Build something. Let us know how it goes.”

Bounties: “Build this specific thing. If it works, you get paid. If it doesn’t, you don’t.”

One wastes less money. You can guess which.

Why This Actually Works (Not Wishful Thinking)

This model is proven and cheap for three reasons:

1. It’s Already a Multi-Trillion-Dollar Reality

Open-source and platform models aren’t theoretical. They’re a multi-trillion-dollar economic reality.

WordPress, Linux, Android, Chrome all built this way. Combined value: trillions. Combined cost to build cores: billions.

The math works.

2. AI Makes Building Software Radically Cheaper

AI coding assistants (GitHub Copilot, GPT-4, Claude Code) dramatically reduce time and cost to develop software.

What used to take 10 developers six months: 2 developers can do in six weeks.

This supercharges community-driven development. Lower barrier to entry. Faster building. Cheaper plugins.

AI doesn’t replace developers. It makes them 10x more productive.

3. Governments Already Do This (And It Works)

Public bodies have a strong track record with bounties and prizes to solve complex problems more efficiently than traditional procurement:

  • XPRIZE: Private-sector space travel (worked)
  • NASA Centennial Challenges: Lunar lander, space robotics (worked)
  • Department of Defense bug bounties: Cybersecurity (worked)

All succeeded. All cost less than traditional procurement. All delivered better results.

Bounties work. Not experimental.

What Has to Go Right (Success Factors)

For this strategy to succeed, four things must happen:

1. Critical Mass

Your framework needs enough users (patients, researchers, clinicians) and developers to create network effects.

No users = no developers. No developers = no plugins. No plugins = no users. Death spiral.

Solution: Referral rewards drive initial growth. Users attract developers. Developers build tools. Tools attract more users. Flywheel spins.

2. API Quality and Documentation

Your framework APIs must be:

  • Robust: They work reliably
  • Well-documented: Developers can figure them out
  • Developer-friendly: Pleasant to use, not torture

Bad APIs kill platforms. Good APIs create billion-dollar economies.

Non-negotiable.

3. Transparent Governance

The bounty process must be:

  • Transparent: Anyone can see what’s funded
  • Fair: Best solution wins, not best connection
  • Responsive: Decisions happen quickly, not after everyone dies

Corruption kills trust. Trust is the foundation of open-source communities.

4. Clear Roadmap

Your core team must maintain and communicate a clear vision (detailed in Canonical Roadmap).

Developers need to know where the rails are going so they can build accordingly.

Ambiguity kills momentum.

The Result

If these four conditions are met, your decentralized framework for drug assessment can foster a thriving global network of tools that delivers medical innovation at a fraction of the cost of centralized, top-down development.

WordPress proved this works for websites. Linux proved it works for operating systems. Your framework will prove it works for curing disease.

Or it won’t, and everyone continues dying from preventable things. Your choice.