Existing modes of Free Software funding, like SaaS, enterprise hosting, and advertising-based models - they distribute funding unevenly and are susceptible to extracting financial gains at the cost of both end users and contributors.

Most DAOs and NGOs are problematic for similar reasons, favoring centralized ‘whales’ and speculators. By accidental design, they encourage rent-seeking, entitlement, and systematically leave inept or apathetic people in strong veto positions.

If we're honest about how this affects FOSS authors, it's simple: developers tend not to be commercially-minded, and give up the end-user relationships, and the revenue control that goes with it.

Our goal is to create am on-chain SaaS, with trustless and transparent revenue distribution to FOSS authors, based on actual usage.

As AMMs are to banks, we are to SaaS.

Guiding Principle: Equitability

We prioritize equitability and trustlessness. Our goal is to distribute funds based on actual usage, moving away from traditional models (such as SaaS, open core, and delegation populism) that often concentrate power and leave creators unrewarded.

  • How can we ensure our system remains equitable as it evolves?
  • What challenges might arise in maintaining these principles?
  • How can we balance immutability with this? Can we have long-term guarantees or anti-erosion systems that protect fund distribution to authors, but also have adaptability to include contributors at later stages or of different types? How can we keep the authors and main contributors in power?

Mechanism: ZK-OAuth & ZK-Activity

We're exploring a zero-knowledge (ZK) OAuth mechanism, allowing trustless user authentication and anonymous activity tallying. This approach emphasizes actual user interaction as an input for redistribution. (As a highly composable primitive, this sidesteps the need for identity proofs compared to most sybil-naive QF models, for example.)

  • How can we ensure the ZK mechanism remains robust and secure?
  • Which ZK platform makes sense for this? Seems feasiable on Mina but Mina mainnet isn't ready. Starknet maybe?
  • Are there other mechanisms that align with our principles?
  • Any other mechanisms that feel worth building or experimenting with?
  • How can we make this mechanism more accessible and understandable for all?

Collaboration Culture: Pluralistic Building

We can't predict which ideas will really work until we try them. So experiment, iterate and prototype with users. Share progress with Super Shadowy peers. At its core, a bi-weekly WIP Wednesday meetup.

  • How can we foster a culture of open experimentation and support?
  • What guidance might help streamline our collaborative ?
  • Are there existing collaboration models you'd like us all to consider?

If these 3 feel right to you, get super shadowy