Great questions! We all need something constructive at this point. Indeed, “what is the solution” is what must be individually and collectively asked, and worked upon. I have extensive thoughts on this matter, as evidenced by the length of this response. Get some coffee!
It’s possible to look at FRUITs from two different perspectives.
Inspired by Indian Democracy and Requirements of Overall Transparency
This is the classic RTI. Government is “opaque”, and hence the need for the “right”. Here, CAs are the middlemen. They balance the needs of privacy of the client. They also follow scalable, established best practices of their own profession. Plus, a CA may also be an “artist”. Creative Accounting is a thing - and for many clients, a benefit (even for ITR filing at an individual level).
In this entire process - the granularity of the data suffers and mostly gets lost. However, this model is practical, and thus reflects society and power structures. And it not right to call this wrong. Indeed, its lineage can be traced to history and its power struggles, and it does work, albeit to a limited extent. And let’s face it – at the scale of our democracy, any working implementation is quite something.
Translated to FU, the notion becomes - FU is “opaque”, and hence the need for the “right”. But the CAs are still in the loop. And I made the point repeatedly that FOSS United is a Community of Communities. Not a single homogeneous conglomerate.
And yes, FU is opaque, even from the POV of GB members, courtesy Chakravarti CEO of the FOSS United janapada. If you notice closely – that’s an absurdity, and not name calling. Indeed the notion that a Chakravarti can hold dominion over multiple janapadas is ridiculous - the two are diametrically opposite concepts. I have used those labels to illustrate the point that the governance models do not align. FOSS United is a community of communities, as I noted in my GB meeting reflection talk. Opaqueness of FU is not limited to financial matters only as of now, btw, but this post is only about finances.
The primary problem with our current model is that we start from the CA’s report. Which, to be frank, is ridiculous! Yes, it’s important to have that public as a good practise, but it is such an obfuscation that limiting ourselves to such “transparency” basically limits our gains to statutory compliance.
FUF has a relatively small number of IN transactions : donations(CSR), sponsors, diversity sponsors. Maybe bank interest on FDs! Beyond that FU already has a system of claiming reimbursements. This gives us all the data – the exact purpose of all payments, details such as recipient, purpose, category(event etc) including bill scans where relevant, and transaction IDs - really granular data. This is the root database of the FRUIT. If the data is well defined, with the proper associations/categories, this is a forest (in graph theory terms)
Inspired by Freedom Principles
What do we aspire we be - or become, as a community ? How open ? What level of transparency ? How can we push the limits beyond what CAs and indeed what even the whole country or even the entire world already terms “best practices” ?
Indeed, we need an approach beyond open data. A simplistic implementation of open data could be: CC Licensed Bank Account statements, uploaded monthly to a portal, ideally public. This lists all transactions individually - timeline, CREDIT/DEBIT, but will obfuscate details. Try associating your bank account statement with your UPI payments 
Now, on top of this simplistic implementation, layer the fact that the overall database is exposed using an API.
But then we have to consider… ?
Privacy
Privacy is an essential requirement. Two potential reasons:
- Donor right to be remain unknown to random people (but not to Law enforcement!). This has to be guaranteed. Suitable anonymization techniques should be considered (end of the article)
- Recipient right to privacy. Ideally all data public for accountability. But see below
- Staff right to privacy. Should Staff salary be private ? I don’t think so. We have to hold FU to higher standards than the Govt of India !!!
Implementation
Well, you are the API guy of our forum. So, who am I to speak on this topic anyways, right ! Should it be streaming, static, downloadable publicly/conditionally, regulated in access, etc are all those are policy decisions.
That said… let’s address few remaining tidbits
Purpose of Incoming Payments
Incoming payments (could be CSR/donations) generally have a specific purpose. Right now, this is a couple of buckets - sponsoring an event, diversity sponsorship. The “Industry Partnership” is a generic bucket. Can we do better ? So, let’s look at some applications of more buckets…
Volunteers run events. Money comes from the generic bucket. Who should pay for tea ZERO resistance RSVPs creates “tourists”. Volunteers are left guessing about how many people will actually come. Instead, tie RSVP to a small payment. 15 rupees for tea/coffee. Ask which ones they prefer. This friction proves intent, reduces guesswork and hence waste. Better outcomes for all.
Let’s say a volunteer is making a pitch for “something”. Local chapter needs lets say some infrastructure. Infrastructure could be anything - from payment for AWS credits to a HDMI cable. Anybody from the community can pool funds. This being such a sweeping application, naming these buckets will now be a thing, but that can be handled later ! Note that the “local chapter” here is also a “virtual account”. Thus there is an implicit hierarchy at ZERO cost of maintaining extra bank accounts, and additional overheads.
Traceability
As you can probably see now, the exported database, via the API, empowers everyone to do their own sleuthing when so needed But most applications of course will be relatively simpler.
The beauty of this entire scheme is that any donor can trace the tree of their gifts !
- Diversity sponsors can trace who received their gifts ! And recipients can trace them to their donors - AHA ?
- All budgets are ultra transparent.
There are of course numerous applications, and all the open data guys understand those. So I won’t be piling on more text here.
Anonymization
Donors have a right to anonymity, ensuring their privacy. And just to remind everyone very specifically - from the peering eyes of the random janata ONLY - not to Law Enforcement !
Best implementations of anonymization must preserve the notion of verifiability. In the sense that an anonymous donor must retain the ability to trace down to their recipients, while preventing the opposite !
How does this get implemented ? This is somewhat complex. A similar, but not the same condition requirement is present in The Rupee Fund. In the democracy of The Rupee Fund, FOSS folks, acting as good citizens, pool funds - each to their capacity, beginning at Rs 15, exactly the same as a cup of tea! We accumulate 3 months of funds to make it a sizeable chunk, calling it a season. Every season, the same good citizens vote on projects - where each citizen has a right to nominate their project. At the end of the voting, funded projects can say thanks to their voters. And voters can say where how their votes contributed to their favourite projects. And why this sidetrack ?
The Rupee Fund already documents the technical details of anonymization. So please go there for the next level of details. And subscribe to The Rupee Fund already, will ya!? We are urging people to sign-up, and we have notionally raised Three Lakh Rupees a year from just 75 people. Just a few thousand folks can do amazing things.. just look at our Roadmap and how the community benefits here. The power of community is phenomenal. You just have to believe in it and stop thinking about what 15 rupees can do - it can do a LOT, but we have to all come together to put in our bit first! Thank you for your attention to this matter !!!
Federation
The funding hierarchy of this design supports federation, as a layered solution. The boundary of each federation boundary is essentially a bank account. Thus, the path of funds from a donor to a recipient may include multiple hops, with each entry and each exit crossing a federation boundary, and thus needing a separate account transfer transaction. Each transfer may add some friction - which will manifest as a transaction cost. This overhead is attributable entirely to the federation network, rather than to the design. Money crossing a federation boundary thus creates a “virtual” source of funds, and a “sink”, corresponding to either ends.
Federated boundaries also enable another interesting possibility. Each federation could vary in terms of the licensing of the data. If a federation chooses a “viral data” license, such as Open Database License (ODbL), then what happens ? The essential requirement here now is that the path for every individual flow of funds must be compatible in terms of licensing requirements. Thus, transfer down the hierarchy is, realistically speaking, a naturally compatible path.
Law Enforcement
This is something we generally disregard, or worse, treat as an irritant. Now, that’s a fundamental mistake – when you are trying to build a scalable design. Where money flows, trouble follows! Locally, Law Enforcement is a highly complex, deep-hierarchy job that the average techie has no real appreciation of.
The radically open architecture suggested in this document creates an interesting balance:
- Donors may be anonymous, but are still traceable to meet law enforcement requirements
- Recipients are not anonymous. This is essential for transparency, and proving and improving the fairness/coverage of allocation processes. This is a requirement for our racuous democracy.
- Law enforcement can work transparently across federation boundaries. This simplifies tracing, but more importantly, builds trust in a transparent way. As the collective scales, so does the trust !
Overall, the hope is that the collective follows all the laws and the rules, not just in intent, but in enforceability. Not eventually, but from Day 0. This is the ultimate safety shield the collective requires. Other standard architectures, rooted in western ideas of “privacy”, prioritize “privacy” of the individual over the collective. This leads to disastrous scenarios in federated architectures. Thus, not a fit for our country, which is unique in the sense of being the land of unity and diversity.
Consequences
That’s a clickbait heading. Openness and transparency must be at the very heart of our existence. So we have to think of the consequences for others, not for us ! Seems radical ? It is !
But beyond that, the question we all have to ask ourselves is - how deep and how wide can we make the overall database of overall funding of the FOSS ecosystem. The CC-BY-SA-4.0 license is an attribution license. If we use that, anyone can consume our data for sure. And the community is required to get the credit.
Lastly, let me address the actual intended goal of MY (attribution: MY!) design. The most significant consequence of this approach : unification. Running FOSS communities is such a chore. In that sense, anyone coming into the ambit of the FOREST of FRUITs basically gains access to real infrastructure at ZERO cost. This enables small groups to join and run their own affairs. They can mind their own FOSS business, follow their own rules, in their own way. FOSS Club or Meetup Group, to each their own. And everything including their own CODE OF CONDUCT! Thank you for your attention to this matter !
Imagine us doing even political flex at some point in time in the future - while remaining strictly an apolitiical community of communities !
FOSS United - one nation, all communities, one bank account !
Afterword
Find the holes in this design. It’s not implemented yet, but is entire feasible democratic, enables diversity and inclusivity. Probably works at scale, and scales the community simultaneously.
The technical implementaion of this is simple, but the human angle is that it must be done collectively, and right from the beginning - with consensus.
With this model, we can have both “Community of Communities” (real possibility: actually any arbitrary hierarchy!), existing simultaneously with “One Community”. That is FOSS United… OUR community ! Cheers!
Attribution
CC-BY-SA-4.0
Name : Shree Kumar (Real Name, in Real Life)
LinkedIn : https://www.linkedin.com/in/shreekumar3d/
Twitter/X : shreekumar3d
Github : https://github.com/shreekumar3d/
Call to Action
You may also use any of the following Given Names, in conjuction with my IRL Name for Attribution:
- Corpo-Rate Kumar - if you appreciate this design in general ! (ensure the captital C, specifically!)
- Paise Vasool Corpo-Rate Kumar or PVC Kumar. Fix the plumbing, or optimize communities, Upvote the idea ?
- FULL PVC Corpo-Rate Kumar or FPVC Kumar. When you realize that this design does cover not just many, but every possibility. The AHA moment when it all comes together!
Let’s make this happen. Optimize for the ENTIRE COMMUNITY, COLLECTIVE GROUPS, and downwards. Not ONE INDIVIDUAL.
Sign up to the The Rupee Fund today, and let’s together build this architecture, evolve and scale it, in a democratic manner. We do have a suggested entry cost of Rs 15 a month, but that must not matter! And… thank you for your attention to this and that matter!