A communication network can let users of different operators talk to one another while much of its shared maintenance depends on a few funders. Those conditions can coexist. Matrix provides an observable example.
Under the Matrix protocol, users on different servers can join the same room. Each participates through the server holding their account, and the relevant servers synchronize messages. Organizations can keep their own operational arrangements while talking to outside users. Shared communication does not require everyone to move to one service. How Matrix communicates
Interoperability does not, however, determine who pays for the common foundation.
In its report for financial year 2025, published in 2026, the Matrix Foundation describes membership as its main income source, alongside donations, event sponsorship, ticket sales, and other income. The report also says that Automattic accounted for half of income, while the foundation remained substantially dependent on Element’s financial and in-kind support. The reporting period runs from November 2024 through October 2025. Introduction to the first public annual report
Broad benefits do not automatically produce evenly shared contributions. There is organizational work between them.
Two costs, two reasons to pay
One cost is easy for a user to understand. My server needs storage and bandwidth, someone must handle failures, and I need help with account problems. Capacity and response quality affect me directly, giving a hosting provider something concrete to charge for.
Shared maintenance is harder to connect to an individual purchase. Specifications need upkeep, implementations must remain compatible, and newcomers need a way to join. Many organizations benefit. If one stops contributing, it can often continue using the results maintained by others for a while. Adding users does not automatically deliver more money to maintainers.
That explains why “the code is open, so the community will carry on” is not a budget. Contributing a patch and accepting long-term maintenance are different commitments. When a few people have maintained something for years, a successor needs more than source code: time to understand the system and funding to keep working on it.
Matrix’s public-server pricing effort illustrates how a specific service can pay for its own costs. In June 2025, the foundation proposed premium accounts, using paid services including media usage to support the matrix.org public server. It described infrastructure, operations, moderation, and support costs. The later annual report records the program’s launch at the end of the financial year. Public-server funding proposal, annual-report introduction
Users pay for a ready-to-use service while other operators can still connect through the common protocol. There is no necessary choice between everything being free and a closed network.
A service’s ability to charge still does not guarantee enough shared maintenance. An operator may invest revenue in compatibility work, or prioritize features its own customers need. Both can be reasonable expenditures. Neither should be assumed to have happened in the other’s accounts.
I therefore favor making two payment commitments explicit. Hosting buyers should know the capacity, responsiveness, and support they receive. Funders of the shared foundation should know which public work gets sustained and how participants discuss priorities. Calling everything “ecosystem development” makes returns harder for funders to assess and real gaps harder for maintainers to explain.
Connections must repay the work of keeping them alive
Open connections are most worth building when collaboration repeatedly crosses operators and participants have reasons to retain their own services. They may already have invested in different systems; migration would interrupt existing work, yet communication must continue. Matrix’s interoperability addresses that situation.
Elsewhere, one shared service may suffice. With few participants, similar needs, and agreement on operations, building multi-party synchronization and version negotiation early can draw attention away from the collaboration itself. Openness is valuable for the constraints it removes, not for the number of nodes on a network diagram.
For a collaboration network such as ToWow, this implies a specific requirement: find recurring losses at boundaries before deciding what to connect. Repeated registration, manual relaying, and lost collaboration records can be starting points. Count the upgrades, debugging, and maintenance the connections add as well.
If the collaboration work saved remains smaller than the maintenance work added, narrowing the connection scope is a reasonable adjustment. If connections keep producing benefits, maintenance should gradually move from a few people’s extra enthusiasm into routine expenditure participants are willing to bear.
The Matrix report cannot establish that any one funding model works universally. It reveals a reality often deferred in open-system design: communication can be distributed while maintenance funding remains concentrated. Keeping multiple independent operators requires tending the relationships that let shared maintenance continue.
A reliable connection usually means someone works on it every month. An open network’s plan should show where that labor sits.