How to Market Open-Source Software

Partially inspired by https://humanity.game/

What Governance Platforms, Mesh Networks, and Economic Commons Theory Teach Us About Building Digital Infrastructure People Actually Want to Use

You don't market open-source software the way you market proprietary products. You can't, really—the economics are fundamentally different. When anyone can copy, modify, and redistribute your code for free, traditional marketing strategies collapse. You're not selling scarcity; you're coordinating abundance.

The question isn't "how do we convince people to buy this?" It's "how do we make cooperation the obvious choice?"

The answer comes from observing what already works: participatory governance platforms, community-owned infrastructure networks, and economic commons management. Combined with specific legal innovations in software licensing, these patterns reveal a coherent strategy for building digital infrastructure that people choose because it serves their interests—not because someone convinced them.

Start With Observation: What Consul Democracy Teaches Us About Real Needs

Before you can build something people want, you need to understand what they actually need. This sounds obvious, but most software development starts with what developers think is cool, not what communities require to function.

Consul Democracy provides a useful model. Originally developed for Madrid's municipal government, it's now used by over 135 institutions across 35 countries for participatory budgeting, collaborative legislation, and citizen proposals. What makes it relevant isn't just that it's open source—it's that it emerged from observing actual governance needs.

Madrid didn't start with "let's build voting software." They started with "citizens need ways to propose policy, debate it publicly, and allocate municipal budgets transparently." The software became a documentation of those observed requirements. When other cities needed similar capabilities—Barcelona, Paris, Porto Alegre—they didn't need convincing to adopt Consul. They recognized their own needs in it.

This is the first principle: observe coordination problems that already exist. Don't invent problems your software solves. Find problems communities are already struggling with, document those patterns, then build tools that address them.

Other governance platforms demonstrate similar patterns:

• Decidim emerged from Barcelona's need to coordinate participatory processes across neighborhoods

• Loomio developed from Occupy movement requirements for consensus decision-making at scale

• Pol.is grew from Taiwan's need to find common ground in polarized conversations

Each observed specific coordination needs, built tools to address them, then found natural adoption among communities facing similar challenges. They didn't market solutions to invented problems. They documented solutions to observed ones.

NYC Mesh and Federated Infrastructure: Make Self-Interest Align With Cooperation

NYC Mesh demonstrates the second principle: align economic incentives so helping the commons helps yourself.

Here's their model: instead of paying Verizon or Comcast $70/month for internet, you pay NYC Mesh a one-time installation fee (typically $160-290). You get internet access, but you also become part of the infrastructure. Your rooftop becomes a relay point. Your node helps your neighbors get connected, and their nodes help you get better coverage.

The more people join, the stronger everyone's connection becomes. Growth isn't marketed—it's incentivized. Every new node makes the existing network more valuable. Self-interest and collective benefit align.

This pattern appears across successful federated infrastructure:

Guifi.net in Catalonia operates 37,000+ nodes using commons-based spectrum sharing. Participants own their equipment, contribute to network infrastructure, and benefit from expanded coverage. The network grew from 4 initial nodes in 2004 to covering most of Catalonia because joining served individual interests while strengthening collective infrastructure.

Freifunk in Germany follows similar logic—decentralized mesh networks where participants contribute bandwidth and routing capacity while gaining access to community internet infrastructure. Over 41,000 access points exist because the more nodes participate, the better everyone's connectivity becomes.

Mastodon and the broader Fediverse demonstrate this pattern for social infrastructure. Individual instances serve specific communities while federating to provide network effects. You're not selling people on Mastodon—you're showing them they can run their own social media infrastructure while maintaining connection to a broader network.

The marketing insight: don't convince people to sacrifice for the commons. Show them how contributing to the commons serves their direct interests.

From Ostrom to Stallman: Commons Theory Becomes Digital Infrastructure

Elinor Ostrom won the Nobel Prize in Economics for demonstrating that communities can manage shared resources without privatization or government control—if certain conditions exist. Her work analyzing forests, fisheries, and irrigation systems revealed consistent patterns: clear boundaries, participatory governance, graduated sanctions, conflict resolution mechanisms, and autonomy from external authorities.

The question for digital infrastructure becomes: how do you prevent the tragedy of the commons when resources are infinitely reproducible?

Richard Stallman provided the answer through licensing innovation. His GNU General Public License (GPL) established "copyleft"—using copyright law to ensure software remains free. Anyone can use, modify, and redistribute GPL code, but all derivative works must also be GPL licensed. This prevents enclosure: corporations can't take commons-developed code and make it proprietary.

But GPL had a limitation. The "distribution trigger" meant you only had to share source code if you distributed the software. Companies like Google could modify GPL code extensively for internal use (Gmail, Google Search, etc.) without releasing those improvements. They extracted value from the commons without contributing back.

The Evolution to AGPL-3: Closing the SaaS Loophole

Stallman recognized the structural problem. As software moved from distributed products to centralized services, the GPL's distribution trigger became ineffective. Software as a Service (SaaS) companies could use GPL code to run services without ever "distributing" the software to users—technically they were only transmitting data outputs.

The GNU Affero General Public License version 3 (AGPL-3), finalized in 2007, added a network interaction clause. If you run modified AGPL code as a network service (accessible over a network), you must make your source code available to users of that service. The trigger isn't distribution—it's interaction.

This seemingly small change has profound implications for digital commons:

MongoDB originally used AGPL-3, then switched to the even more restrictive Server Side Public License when Amazon Web Services started offering MongoDB as a managed service without contributing improvements back. The license evolution demonstrates the ongoing battle between commons-based development and corporate enclosure.

Nextcloud uses AGPL-3 to prevent companies from taking their file-sharing platform, modifying it, and running it as a proprietary service. Users maintain sovereignty over their data and tools.

Mastodon uses AGPL-3 for the same reason—ensuring that any improvements to the federated social network remain available to the commons rather than captured by corporate platforms.

The pattern Stallman identified: legal infrastructure determines whether digital commons remain accessible or become enclosed. AGPL-3 creates what economists call "resource starvation mechanisms"—corporations must either contribute improvements back to the commons or develop expensive proprietary alternatives. The commons becomes the path of least resistance.

This is Ostrom's commons theory implemented in code: clear boundaries (AGPL license), participatory governance (open development), graduated sanctions (license enforcement), and autonomy (community ownership).

NTARI's Synthesis: Making Commons-Based Infrastructure Inevitable

Understanding these patterns—observed needs from governance platforms, aligned incentives from mesh networks, and legal protection through AGPL-3—reveals a coherent strategy for open-source adoption. You don't market open-source software. You create conditions where using it becomes the smart choice.

This is what NTARI builds:

Software Development Studio: Address the coordination problem governance platforms solve. Most developers struggle with project management, fundraising, and infrastructure. The SDS removes those barriers—automatic backups, shared advertising budget, professional presence, grant writing help, team coordination. These aren't marketing gimmicks. They're documented needs from observing hundreds of open-source project failures.

SoHoLINK: Apply the mesh network incentive model. Instead of asking people to donate server capacity for the commons, pay them for it. Running NTARI infrastructure earns money rather than costs money. Self-interest drives commons contribution, exactly like NYC Mesh nodes.

NTARI OS: Remove adoption friction. Pre-configured Linux distribution with everything working together out of the box. The same principle as Consul Democracy or Decidim deploying complete governance stacks rather than disconnected tools.

SEEDs Training: Make commons infrastructure economically sustainable for participants. Learn NTARI tools, get certifications, acquire job skills that employers pay for. You're not volunteering for the commons—you're building marketable expertise while the commons benefits.

.ntari TLD: Establish clear commons boundaries (Ostrom's first principle). AGPL-3 licensing required for all .ntari domains creates immediate verification. The web address itself signals "verified commons-based project," reducing investigation costs for users.

Specialized Platforms: Address observed coordination problems. Agrinet for urban agriculture networks, LBTAS for technology service evaluation, Q-Zoo for community detection and quantum collaboration. Each solves documented needs rather than invented ones.

Academic Integration: Normalize commons infrastructure through education. When NTARI tools become part of college courses and library systems, adoption happens through institutional learning rather than marketing campaigns.

The synthesis: Build legal infrastructure (AGPL-3) that prevents enclosure, create economic infrastructure (SoHoLINK) that rewards contribution, provide coordination infrastructure (SDS) that removes barriers, develop educational infrastructure (SEEDs) that makes participation profitable, and establish verification infrastructure (.ntari) that builds trust.

You're not convincing people to choose commons-based tools. You're making them the obvious choice.

The Alternative Vision: Network States and Exit

Balaji Srinivasan's The Network State proposes a different model: competitive governance through exit rather than cooperative governance through voice. Build parallel institutions with clear membership, accumulate territory, gain diplomatic recognition, become sovereign.

Charter Cities Institute (CCI) pursues similar logic—new cities with experimental governance, typically in developing nations, often with significant corporate involvement. Próspera in Honduras demonstrates the pattern: private governance, special economic zones, opt-in citizenship.

These aren't necessarily bad ideas. Exit creates competitive pressure on failing institutions. Experimental governance can discover better coordination methods. The Seasteading Institute and similar projects push boundaries of what's possible.

But there's a fundamental difference in economic logic.

Network States and Charter Cities typically operate through proprietary coordination infrastructure. Someone owns the platform, the governance systems, the coordination tools. Members gain services by accepting terms. Growth benefits the owners who capture increasing returns to scale.

This is the pattern of platform monopolies: Facebook doesn't charge you money—it charges you sovereignty over your social graph. AWS doesn't charge municipalities prohibitive rates initially—it charges them lock-in to proprietary infrastructure. The business model is enclosure of commons.

Commons-based infrastructure operates through permanent public protocols. No one owns the coordination systems because they're legally structured to prevent enclosure (AGPL-3). Members gain services by contributing to shared infrastructure. Growth benefits all participants through network effects that remain accessible.

The question isn't whether Network States or Charter Cities can work—several likely will. The question is: do you want your fundamental coordination infrastructure proprietary or permanently accessible?

Your city's emergency response systems, agricultural networks, education platforms, and governance tools—should those run on protocols that anyone can audit, modify, and deploy? Or on platforms that corporate entities control?

NTARI's model says: build the commons first, make it economically sustainable, prevent its enclosure legally, and let communities choose whether to participate. Network States say: build competing proprietary systems and let the best institution win.

Both might succeed. But only one creates infrastructure that remains permanently accessible regardless of which organization currently maintains it.

The Dune Problem: Prescience Creates Stagnation

Frank Herbert's Dune presents a warning about technological and social ossification. Paul Atreides gains prescience—the ability to see all possible futures. This seems advantageous until you realize the implications: knowing all futures means the most likely path becomes locked in. Prescience creates the Golden Path—a future so rigid that humanity stagnates for thousands of years under Leto II's tyranny, specifically designed to be so oppressive that humanity learns to evolve beyond prediction.

Herbert was describing what happens when coordination infrastructure becomes total. Complete information, perfect prediction, optimized control—these create systems so efficient at maintaining themselves that they stop evolving. The Butlerian Jihad that precedes Dune's timeline destroyed all "thinking machines" precisely because they made humans dependent on machine intelligence for decision-making.

The parallel to modern platform monopolies is direct. When Amazon knows what you'll buy before you do, when Facebook predicts your opinions, when proprietary algorithms determine what information you see, coordination becomes prescient. The platforms don't just respond to needs—they shape them, predict them, ultimately constrain them.

This is the future Network States and proprietary governance platforms risk creating: hyper-optimized coordination so efficient at managing human activity that it calcifies. The most successful proprietary platform wins, captures coordination infrastructure, and human communities lose the ability to evolve beyond what that platform's incentives allow.

Commons-based infrastructure operates differently. AGPL-3 licensing ensures that no single entity can achieve prescience over the whole system. Any community can fork the code, modify the protocols, experiment with different coordination methods. Evolution remains possible because control remains distributed.

The mesh networks, federated platforms, and commons-based tools don't optimize for total coordination. They optimize for sustainable diversity—many overlapping experiments, none dominant, all learning from each other.

This is the future we're intentionally building toward: not the Golden Path's stagnant efficiency, but the messier, more resilient coordination of communities maintaining sovereignty over their own infrastructure while sharing innovations through permanent public protocols.

Conclusion: Marketing Through Permanence

How do you market open-source software? You don't.

You observe actual coordination needs. You build legal infrastructure preventing enclosure. You align economic incentives so contribution serves self-interest. You remove adoption barriers through training, integration, and pre-configuration. You establish trust through verification systems. You make commons-based infrastructure the path of least resistance.

Then you step back and let communities choose.

Some will choose Network States and proprietary platforms. That's fine—competition drives innovation. But commons-based infrastructure persists regardless. The protocols remain accessible. The code stays forkable. The future remains plural.

That's not marketing. That's building something actually worth using and legally structured to remain available. Everything else is just removing the reasons people might not.

NTARI is a 501(c)(3) nonprofit building community-owned technology infrastructure. All tools are AGPL-3 licensed and permanently accessible as digital commons. Learn more about Agrinet agricultural protocols and LBTAS technology evaluation systems. Support commons-based infrastructure development through direct donation or join technical collaboration in Ntariville.