top of page

When Software Becomes a Hostage Crisis: Building the Community-Owned Emergency Response System

In November 2024, the Norfolk Volunteer Fire Department in Connecticut opened their annual budget meeting to discover their software costs had jumped from $795 to over $5,000—a 530% increase overnight. The software they relied on to track incidents, manage equipment, and coordinate emergency responses had been acquired by ESO Solutions, a company backed by Vista Equity Partners, which manages over $100 billion in assets. Norfolk's entire annual budget was $132,000, barely enough to maintain aging fire trucks and train volunteer crews. Now a software subscription would consume nearly 4% of it.


The Mesilla Fire Department in New Mexico watched costs triple from $4,000 to $12,000. Chief Greg Whited compared ESO's treatment to an abusive relationship: "I'm not going to come back with sunglasses on, covering a black eye. You've taken advantage of my department."

Woman with bruises and wet hair, wearing a black and white plaid shirt, stands solemnly against a green, dotted background.

This isn't happening to one or two departments. ESO Solutions now serves approximately 20,000 of America's 30,000 fire departments. The two other leading software suppliers—ImageTrend and First Due—are also backed by private equity. Together, these three companies control the software infrastructure that volunteer fire departments depend on to protect American communities. And 85% of America's fire departments are volunteer operations, funded through karaoke nights, silent auctions, and community donations.


When the people who risk their lives to protect their neighbors can't afford the software to coordinate that protection, something is structurally broken.


The AT&T Pattern Returns

This is not the first time that essential infrastructure has been captured through consolidation. From 1913 to 1984, AT&T controlled American telecommunications—seven decades where a single company decided how people could communicate, what equipment they could use, and what prices they would pay. Before that, Western Union monopolized telegraphy in the 1860s-1880s through aggressive acquisitions of competing telegraph companies.


The pattern is always the same: competitive markets where multiple vendors serve customers at reasonable prices → private equity or monopoly capital consolidates the market through acquisitions → alternatives disappear → prices spike → captive customers have nowhere to go.


Fire department software followed this script precisely. Much of the software was initially created by people who worked in emergency services and felt a calling to keep prices affordable. Small companies competed on features and service. Then Wall Street discovered the market. Vista Equity Partners backed ESO Solutions in 2021. The acquisition spree began. ESO bought Station Check (equipment tracking), eCore (firefighter scheduling), FIREHOUSE Software (used by 11,000 departments), Digital Innovation, Clinical Data Management, and Lancet Technology. When Norfolk tried to switch to a cheaper alternative—Alpine Software at $2,200 annually—ESO acquired Alpine too. The trap closed.


The same playbook that consolidated telephone service, telegraph networks, and railroad infrastructure now extracts value from volunteer fire departments operating on budgets smaller than a single software engineer's salary.


What Makes This Different: The Architecture of Capture

Here's what makes software monopolies more dangerous than historical infrastructure monopolies: the code runs on their servers, invisible and unchangeable. When AT&T controlled telephone infrastructure, the physical wires ran through public rights-of-way. When railroads monopolized transportation, the tracks were visible. Regulatory intervention could map the infrastructure, measure prices, and eventually break up the monopoly.


Software-as-a-service monopolies are architecturally invisible. The code executes on private servers in data centers in Virginia or Texas. Fire departments click buttons on screens, submit incident reports, manage schedules—but they never see the underlying software. When ESO changes features, removes functionality, or triples prices, departments adapt or lose access to years of historical data locked in proprietary databases.


This is why traditional antitrust approaches struggle with software monopolies. You can't break up what you can't see. You can't regulate what you can't inspect. And you can't create competition when switching costs include migrating decade-old incident records from locked databases.


The problem isn't just monopoly—it's architectural capture. Fire departments don't just pay for software; they're locked into ecosystems that make leaving more expensive than staying.


The Cleanroom Solution: Engineering Cooperative Infrastructure

The Network Theory Applied Research Institute (NTARI) specializes in solving exactly this kind of problem. Our approach is called cleanroom development—a legal method of reverse engineering software that has historical precedent in breaking monopolies.


In the 1980s, IBM controlled the PC BIOS, the fundamental software that made computers work. No one could build IBM-compatible computers without copying IBM's BIOS, which IBM protected fiercely. Phoenix Technologies solved this through cleanroom development: one team examined IBM's BIOS and wrote specifications describing what it did—not how it did it. A copyright lawyer reviewed the specifications to ensure no infringement. Then a completely separate team built new BIOS software from those specifications, creating a functionally equivalent system without copying a single line of IBM code.


This broke IBM's monopoly. Suddenly, multiple manufacturers could build compatible computers. Competition exploded. Prices dropped. Innovation accelerated.


We're applying the same methodology to fire department software. We call it the Community-Owned Emergency Response (COER) system.


Here's how it works:

Phase 1: Specification Development (December 2025)

  • Technical teams examine ESO, ImageTrend, and First Due software in operation

  • We document functionality: incident reporting, equipment tracking, personnel scheduling, hydrant management, inspection protocols, medical information systems

  • Copyright lawyers review specifications to ensure clean-room compliance

  • Fire departments across the country provide input on essential features and missing capabilities

Phase 2: Development (January–October 2026)

  • Separate development teams build COER software from specifications

  • Code released under GNU Affero General Public License v3 (AGPL-3)

  • This means: if anyone deploys COER as a service, they must share the source code with users

  • No company can ever privatize COER improvements—all enhancements remain public commons

Phase 3: Deployment (October 2026–)

  • Fire departments download, deploy, and run COER on their own infrastructure or through trusted cooperatives

  • Improvements made by any department benefit all departments

  • No subscription fees—just server costs (typically $50-200 monthly for small departments)

  • Historical data migrates from proprietary systems to open databases departments control


The Janus Enhancement: Multi-Facing Architecture

But COER will do something ESO, ImageTrend, and First Due cannot: we're building what NTARI calls Janus Facing Architecture.


Named after the Roman god who looks in two directions simultaneously, Janus Facing Architecture allows participants to occupy multiple economic roles at once rather than being locked into single-facing relationships.


Here's the problem with current fire department software: you're always a consumer. ESO provides the software, you pay subscription fees, they control features. You face them as customer to vendor, nothing else.


Janus architecture transforms this. In COER:

You're a Consumer: Access incident reporting, equipment tracking, personnel management You're a Producer: Contribute improvements, customize features for your department's needs, share innovations with other departments You're a Service Provider: Offer training, consulting, or technical support to other departments You're a Cooperative Owner: Vote on development priorities, participate in governance, shape the platform's evolution You're an Investor: Contribute funding or infrastructure that benefits from network effects as adoption grows


This isn't theoretical. NTARI's Agrinet agricultural protocol already implements Janus architecture, allowing farmers to simultaneously produce crops, consume market information, provide logistics services, invest in infrastructure, and participate in governance—all through the same platform. No platform can extract rent when participants occupy all economic positions at once.


For fire departments, this means:

  • Large departments can provide hosting services to smaller departments in their region

  • Departments with software expertise can contribute code improvements

  • Rural departments can pool resources for shared infrastructure

  • All departments vote on feature priorities and development roadmap

  • Improvements flow in every direction, not just from vendor to customer

The multi-facing architecture prevents the formation of new monopolies because there's no single-facing relationship to capture. When everyone is simultaneously producer, consumer, and coordinator, economic rents have nowhere to accumulate.


The Investment: $3,000 Per Department or Municipality

We can build COER with minimal funding because cleanroom development eliminates the largest cost: starting from zero. We already know what fire department software needs to do—ESO showed us. We just need to build it under a license that prevents anyone from ever privatizing it again.


Here's the budget for 2026:

Total Development Cost: ~$90,000

  • Cleanroom specification development: $15,000 (legal review + technical documentation)

  • Software development (8-12 months): $60,000 (volunteer developers with stipends, can be augmented with Claude AI assistance for rapid prototyping)

  • Infrastructure for pilot deployments: $10,000 (servers for departments without their own hosting)

  • Promotion and outreach: $5,000 (documentation, training materials, conference presentations)

With 30 municipalities or departments contributing $3,000 each, we fully fund COER development and deployment. Every dollar goes to building permanent commons infrastructure that no company can ever capture.


What $3,000 Gets You:

  1. Immediate: Input on COER specifications and feature priorities

  2. By 2027: Working COER software you can deploy independently

  3. Ongoing: All future improvements from any department that enhances the software

  4. Permanent: Freedom from subscription fees, price increases, and vendor lock-in

  5. Strategic: AGPL-3 protection ensures no company can privatize the commons you help build


Think of it this way: Norfolk was paying ESO $5,000 annually—and that cost was rising. A one-time $3,000 investment in COER eliminates subscription fees forever. Even if you choose to pay for hosting services from a cooperative, typical costs run $50-200 monthly ($600-2,400 annually)—still less than current monopoly pricing, with no future price spikes.


But more important than cost savings: you control the infrastructure. You own the code. You decide the features. You migrate to better hosting if needed. You can fork the codebase if NTARI somehow fails its mission. The software serves you, not shareholders.


Why This Will Work: Historical Precedent + Network Topology

Cleanroom development has proven legal standing. Phoenix Technologies broke IBM's BIOS monopoly. Sega v. Accolade (1992) established that reverse engineering for interoperability is legal. Sony Computer Entertainment v. Connectix (2000) affirmed that creating compatible software through cleanroom methods doesn't violate copyright.


AGPL-3 licensing has proven effectiveness. Nextcloud, Mastodon, PeerTube, and hundreds of other projects demonstrate that copyleft licenses prevent corporate capture while enabling distributed development. When every server running modified code must broadcast source back to users, improvements flow through the network instead of accumulating in proprietary silos.


Fire departments already operate as cooperatives. 85% of American fire departments are volunteer organizations—community members coordinating to protect neighbors without profit motive. COER simply extends that cooperative model to digital infrastructure. You're already organized to coordinate collectively. COER provides the technical substrate to do it at scale.


The network effects work in reverse of typical platforms. Usually, network effects benefit the platform owner—more users mean more value to the company. With COER, network effects benefit participants. Every department that deploys COER:

  • Validates the software in real-world conditions

  • Contributes improvements that propagate to all other departments

  • Adds to the political coalition resisting software monopolies

  • Demonstrates that community-owned infrastructure works

By the time we have 100 departments running COER, the network effect momentum becomes self-sustaining. By 1,000 departments, COER becomes the default. By 5,000 departments, the monopoly is broken.


The Timeline and Call to Action

December 2025: Complete specification development and legal review; begin recruitment of volunteer developers; launch donation campaign

January 2026: Begin COER development with input from participating departments

March 2026: Alpha release for testing by pilot departments

June 2026: Beta release with core functionality complete

October 2026: General release; deployment support for all participating departments

Ongoing: Continuous improvement through distributed contribution

This is aggressive but achievable because cleanroom development gives us a working specification from day one. We're not guessing what fire departments need—ESO already built it. We're just building it again under a license that prevents monopoly formation.

Your $3,000 donation funds:

  • Specifications your department helps shape

  • Software your department helps test

  • Infrastructure your department controls

  • Commons no company can capture

Make your contribution here: https://www.ntari.org/coerdonations


We're targeting 30 municipalities and fire departments by end of December 2025. Early participants have maximum input on feature priorities and development roadmap. The sooner you commit, the more influence you have on what COER becomes.


Beyond COER: A Template for Breaking Monopolies

Fire department software is one example of a larger pattern. Private equity targets any public service that software can mediate: school lunch programs, prison communication systems, parking enforcement, healthcare records. Wherever software creates dependency, consolidation follows. Wherever consolidation occurs, prices spike.


COER demonstrates the counter-pattern:

  1. Identify monopolized public infrastructure

  2. Cleanroom develop AGPL-3 alternative

  3. Deploy through cooperative ownership

  4. Use Janus architecture to prevent re-monopolization

  5. Let network effects work for communities instead of corporations

If we succeed with fire department software, the template replicates. School lunch coordination. Prison family communication. Municipal parking. Healthcare records. Every monopolized system can be rebuilt as cooperative commons.


But it starts here, with fire departments. With volunteer crews who already understand cooperative coordination. With municipalities that have both the need and the authority to act. With software infrastructure simple enough to cleanroom develop in less than a year.


The question is whether 30 departments commit $3,000 each in the next month.

If yes: between November 2026 and January 2027, those 30 departments control their own software infrastructure, influence how hundreds of other departments coordinate, and demonstrate that monopolies can be broken through cooperative engineering.


If no: ESO Solutions, ImageTrend, and First Due continue consolidating. Prices continue rising. Departments continue spending ever-larger portions of budgets on software subscriptions. And Wall Street investors continue extracting value from volunteer firefighters protecting American communities.


How to Participate

Make Your Contribution: https://www.ntari.org/municipalcoer


Join Development Discussions: NTARI's Slack workspace coordinates COER development with fire departments, software developers, and policy advocates: https://join.slack.com/t/ntari/shared_invite/zt-39injdzvr-a7jY2FVU00fYPopG7gyP4w


Questions or Partnership Inquiries: Contact NTARI at info@ntari.org

The volunteer firefighters who risk their lives to protect communities deserve software infrastructure that serves them rather than extracting from them. The municipalities that fund emergency services deserve control over digital tools their departments depend on. The American public that relies on volunteer fire departments deserves a system where Wall Street can't hold emergency response software hostage.


COER provides the technical architecture to make that possible. Your $3,000 contribution funds the development. The cleanroom methodology provides legal certainty. AGPL-3 licensing prevents future capture. Janus architecture ensures cooperative ownership.


The software exists. We just need to build it again—this time for communities, not shareholders.


Learn More

Fire Department Software Crisis:

Cleanroom Development and Legal Precedent:

AGPL-3 Licensing and Copyleft:

Cooperative Infrastructure Models:

NTARI Projects and Research:


  • Slack
bottom of page