Two documents landed this summer that say the same thing from different continents, and together they close a loop this site has been circling since August.

The first is a study by Nathalia Foditsch and Guilherme Flynn Paciornik, published in June 2026 by Connect Humanity with support from the Digital Infrastructure Insights Fund. It examined Brazil's ecosystem of small internet providers — 11,853 of them operating in 2024, roughly three quarters serving fewer than 5,000 subscribers — and asked what software they actually run. The central finding: open source is not a theoretical alternative for the future. It is already widely used. It cuts licensing costs, unlocks cheaper hardware, and plugs small operators into a global ecosystem of documentation and technical knowledge. The study proposes a sixteen-category stack built entirely from mature open technologies.

The second is a piece from GFOSS, the Greek Open Technologies Alliance, published August 19, that takes the same evidence and applies it to Europe's municipal WiFi estate: 7,200+ municipalities, 93,000+ access points deployed under WiFi4EU. Its conclusion, blunt and correct: the question is no longer how many access points were installed. It is who can still manage, patch, and expand them five years from now — after changing suppliers.

Both documents land on the same bottleneck, and it is not the software.

The bottleneck is the ecosystem around the code

This is the finding worth underlining twice. The Brazil study states that the main obstacles are no longer the maturity of the technology — the tools work — but the ecosystem surrounding them: better documentation, training, technical support, shared reference architectures, and organizations capable of assuming long-term responsibility for maintenance. Making source code available is not enough. What is needed is an ecosystem that can turn code into a dependable public service.

Anyone who has stood up a community network already knows this. The router firmware is the easy part. The hard parts are the runbook, the second operator, the monitoring that pages someone, the patch cadence, and the answer to "who fixes this in eighteen months when the volunteer who built it moved away."

That is an argument for a specific kind of investment — and against a specific kind of procurement.

What the funding model got wrong

WiFi4EU proved Europe can deploy public connectivity at scale: a €15,000 voucher per municipality, free access with no advertising and no commercial exploitation of user data, a minimum three-year free operation. What it financed was day zero. The acceptance criterion was whether the access point worked on the day the project was signed off.

Infrastructure does not live on day zero. It lives in year five, when the vendor's management subscription renews, the firmware is three releases behind, the person who configured it is gone, and the municipality discovers that the management plane — the thing that actually operates the network — was never theirs. A public network whose brain is a vendor's cloud is not a municipal asset with a maintenance contract. It is a rental with better branding.

The fix is specific, and GFOSS lists it as concrete procurement criteria for any successor funding program:

  • Documented open interfaces on everything purchased
  • The ability to export all configurations and data — a municipality can leave with its own network's config
  • The right to self-host the management system
  • Support for open standards, so replacement hardware is a swap, not a migration
  • A supplier exit plan written at purchase time, not renegotiated at crisis time
  • Security updates across the full lifecycle of the equipment, not a three-year grace period

Note what this is not. It is not a mandate to use a specific open source product, and it is not exclusion of commercial companies. It is the opposite of both: a company should win the contract on the quality of its support, not on having made its own replacement technically impossible. That single sentence belongs in every municipal RFP for connectivity infrastructure, and it makes supplier independence a measurable requirement instead of a slogan. Brussels has already made the conceptual move — the Commission's 2026 open source strategy ties FOSS directly to technological sovereignty, interoperability, and public procurement. Public connectivity should inherit the principle.

The stack is not the hard part, and has not been for years

The full stack the Brazil study documents is the same one this site deploys, component for component:

  • OpenWrt as the operating system on access points and routers
  • OpenWISP for centralized management — configuration, monitoring, firmware rollouts, RADIUS — across hundreds of devices
  • FreeRADIUS for authentication, authorization, accounting
  • Zabbix, Prometheus, Grafana for monitoring
  • NetBox or phpIPAM to document the network and its address allocations
  • VyOS, FRRouting, OPNsense at the routing and security edge

None of this is exotic. None of it is a gamble on unmatured code. Every component is older than most of the startups selling its proprietary equivalent, and every one can be mixed and matched to the scale of the deployment — a single fire hall does not need all of it, and should not install all of it.

OpenWISP in particular is worth naming because it is the piece that turns "a pile of routers" into "a network an institution can operate." It went through a 25.10 platform release in October 2025 with point releases through June 2026, and its 2026 development cycle is working through exactly the unglamorous fleet-operations problems that volunteer networks drown in: batched mass commands across many devices with a dry-run before execution, and firmware rollouts that persist — an unreachable device stays pending and the upgrade resumes when it comes back, instead of failing and being forgotten. That is the software embodiment of the patch-discipline argument this site keeps making at every layer, including the edge layer.

And the economics work at the scale where they matter most. A small municipality should not build its own network operations team — but several of them can share one OpenWISP instance and one support contract at regional or inter-municipal level. Shared management platform, shared monitoring, shared expertise. Economies of scale without a single-vendor dependency, because if the support provider fails, the platform and the data stay with the municipalities. This is the regional mutual-aid model, and it is how a fire hall and a town office afford professional operations they could never justify alone.

The honest ledger

Three things open source does not do, said plainly, because the study and GFOSS both say them and the good-faith version of this argument requires them:

Open source is not free. Networks still need people, hosting, cybersecurity attention, and maintenance no matter what the license says. What changes is where the money goes: in a closed stack, public spend leaves as license fees to a vendor; in an open stack, it lands as installation, configuration, training, and support — services that multiple local companies and university teams can compete to provide, building expertise that stays in the local economy. The budget line does not disappear. It changes hands, from a vendor to the community's own capacity.

Open source is not automatically secure. A public wireless network is infrastructure and must be run like infrastructure: regular updates, strict separation of public and administrative networks, secure device management, event logging, configuration backups, a real incident-response plan. Open source provides none of those by itself. What it provides is the institutional precondition for all of them: security and maintenance do not depend on the roadmap decisions of one manufacturer. The code can be audited, vulnerabilities can be fixed by third parties, and a public authority can require update policies and dependency inventories as terms of service. The right formulation is not "open source instead of security." It is open source with professional management, service-level agreements, and named responsibilities.

Migration is incremental or it fails. Not every deployed access point converts to OpenWrt, and pretending otherwise is how big-bang migrations die. The sane sequence: inventory the existing hardware and check compatibility, start with the central systems — monitoring, authentication, configuration management — and replace hardware on its normal renewal cycle. The network gains a controllable management plane first and refreshes its edge over years, not weekends.

Why this matters now

Three threads from this month converge on the same conclusion. Community networks are winning funding and delivering where private ISPs declined to build — the NYC Mesh and DigitalC stories from August. The edge layer is under active attack, and the patching burden lands on whoever owns the router — MikroTrick two weeks ago, and OpenWrt 24.10's security support ended September 5, with 25.12 as the current series. And the evidence base now exists that the FOSS stack is not the alternative path for community networks — it is the one already in use by thousands of small operators who have no procurement department and no margin to burn on licenses.

What has not caught up is the money. Public connectivity funding still mostly buys hardware and a ribbon-cutting. The next funding cycle — in Europe, in North America, wherever public money touches community connectivity — should fund the ecosystem gaps the Brazil study named: documentation in local languages, tested reference architectures, training, shared support structures. Small fractions of existing budgets would close gaps that no amount of additional access points will close.

The one-line criterion for all of it: infrastructure bought with public money should still be controllable by the public institution that bought it — after the supplier changes, after the grant ends, after the volunteer moves away. Every component needed to satisfy that criterion is running in production today, under licenses that never expire. The tools were never the hard part. Procurement that treats them as the default is the part that starts now.