# KERI Foundation - archived

#### This document has been concluded during the members meeting of August 22 2024.
Later editted:
* Clarification of definition of done: Oct 17, 2024

Further development takes place under:
- https://keri.foundation/
- https://github.com/keri-foundation

This document describes the structure of a Foundation for the open-source software suite known as KERI, the code of which resides under the WebOfTrust organization on GitHub with the specification and standardization happening at the Trust Over IP (ToIP) Foundation.

## Reason to get there

flowchart TD

    K(KERI team) -.->A
    A[KERI immature] -->|funding| L[We need a vehicle]
    L ---->|Design| D(charter)
    G(DICE) --> |Proposal|I(charter Switzerland)
    D --> |presence|J(https://keri.foundation)
    I -.->|comparison|D
    D --->M(domicile?) 

These are the **design principles** of the KERI Foundation:
- Minimally sufficient means. In a way that people can use KERI without understanding and pay for it "as you go" 
- Reduce complications for developers, implementers, and users of the KERI Suite in that order.
- A lead role for KERI inventor and lead-developer Dr. Samuel M. Smith
- A role-based organization model that anticipates international growth but can act small
- A balanced and transparent decision-making process that involves key stakeholders
- Smaller autonomous working groups to work on delegated objectives; directed funding.
- Improve and maintain the open source code base. (Find funds to) Manage the open source development of the KERI Suite based on its standards documents and put it in a broad perspective.
- We look for a domicile that can grow with what the KERI foundation should become in the long run and with a broad scope.

The essence of this document is a plan to align with the vision of KERI inventor Samuel M. Smith and other stakeholders through thoughtful internal discussion before public evangelism.

## Environment

KERI acts over different axes in the security space and solves hard problems simultaneously.

KERI faces opposition due to its efforts to demonetize multi-billion companies.

The problem with Internet **security** is that it’s based on flawed identity, and security experts don’t understand identity well enough to fix it.

> The problem with Internet **identity** is that it’s based on flawed security, and identity experts don’t understand security well enough to fix it.
> KERI’s design reflects a sufficient understanding of both security and identity to fix both Internet identity and Internet security at the same time.
> ~ Samuel Smith, August 2024

## Scope of this document
This document answers the following questions about the new foundation:
- What should be its objectives?
- What could be a matching structure for donations?
- How to reward donations?
- How to manage foundation directorships and memberships?
- What does the higher level concept look like of our teamwork and roles & responsibilities?
- How do we integrate business and not-for-profit: be *coopetive*?
- What should be the deliverables of the foundation?
- How will decisions be made?
- How will it be managed, and how will this effort be rewarded?
- How do we regularly sync with the KERI founder's vision?
- How to decide on marketing?
- What could be its domicile(s)?

We differentiate into high level objectives via goals (GOAL) to detailed targets (TRGT).

## Long-term objectives (LTO)

LTO1 - The objective of the KERI project is to create the infrastructure for the trust-spanning layer of the Internet in the most open-source software license. **The foundation should provide the financial resources to overcome any barriers.**

"LTO2: The foundation's long-term objective is to establish a not-for-profit organization that generates funds. This organization will ensure the security and reputation of the KERI Suite while supporting its user base and donors with open-source code, various services, and transparent business relationships with companies."

"LTO3: With financial resources secured and the foundation's structure established, we can focus on maturing the tooling (proof of concept). Allocating funds takes precedence over all other considerations, such as supporting the open-source base. Our primary goal is to reduce complication by addressing the 5 W's: Wallet, Witness, Watcher, Web, and Wizard."

### Why exactly is this the primary focus?

People don't want to understand KERI, so we have to invent and implement a way to prevent incorrect use—"you can't use it incorrectly."

#### Sam Smith's considerations
by: Sam Smith, July 2024

I found this in an introduction to a book on web systems design.  (https://hypermedia.systems/foreword/)

> "By the year 2000, the technical foundations of "the web" were documented in Roy Fielding's PhD dissertation "Architectural Styles and the Design of Network-based Software Architectures"). In that work, Fielding defined the architectural model of REpresentational State Transfer or REST. This set of system properties and implementation constraints have proven — even a quarter-century later — to be a reliable model for designing and building the intertwingled machines that today affect billions of people around the globe.

> Even though Fielding's work was important, it wasn't until Leonard Richardson and Sam Ruby published "RESTful Web Services" in 2008 that the REST model became well-known in software architecture and development. Backed by the Ruby programming platform, the ideas behind Fielding's REST model became de rigueur for creating web-based services and client applications.
> One of the reasons Richardson and Ruby's work was so important was that, unlike dissertations and futuristic predictions, the RESTful Web Services book outlined a practical working framework for building powerful applications for the Web. It described not only the power of REST but also provided step-by-step instructions on how to build them. Richardson and Ruby brought together the hypermedia scholarship of the previous twenty years all in one place."

I want to emphasize the last paragraph. ReST's real power only became popular after the Ruby language and framework were developed, which provided mature tooling for ReST.

It made it so anyone could use ReST correctly without really understanding ReST.

Likewise, we need to build a full tooling suite for the KERI infrastructure. The 'I' in 'KERI' (i.e., Infrastructure) is the most important—the [5 W's](#Reduce-complication). Only then will there be any significant adoption of KERI.

#### Derived secondary objectives
TRGT1 - We must make an elevator pitch for this objective and keep it simple.

TRGT2 - We need to silence the naysayers and prove them wrong. The OIDC fans' arguments will always be that KERI is not mature. Well, surprise.

GOAL1 - The foundation will have business objectives, not just the goal of improving the world.

### Strategic objectives
These are things you can strive for but can't just do.
GOAL2 - find the funds and the resources for the creation of KERI tooling: money and engineering (the right person on the job)
- Reduce complication by the 5 W's: Wallet, Witness, Watcher, Web, and Wizard (GOAL1)

#### Derived secondary strategic objectives
- GOAL3 - successful adoption of the KERI suite. (KERI, ACDC, CESR, and supporting tools like Keria and Signify)
- TRGT3 - Support other programming languages to become more versatile
- TRGT4 - Support KERI Suite implementations: installation, configuration, tailor-made extensions and use
- TRGT5 - Enhance role-based and authority-based governance models with the technical stack so real-world applications become valuable and legally embedded.

## Tactical objectives
Things you can do or decide for. There's an overlap in these bullet points:
- TRGT6 - Mature the KERI reference code base in the Python programming language to be able to deliver even better
- TRGT7 - Build "One-click KERI": Reduce complication by implementing the 5 W's: Wallet, Witness, Watcher, Web, and Wizard.
- TRGT8 - Omnipresent Witness and Watcher services

#### Derived secondary tactical objectives
- GOAL4 - Create educational resources for the KERI Suite to make it more comprehensive and comprehensible
- TRGT9 - promote its unique features to get global adoption and bootstrap the underlying infrastructure
- GOAL5 - step by step from a centralized (benevolent dictatorship) - to a decentralized direct-funding/working-group -based decision-making process.
- TRGT10 - Tiers donations. The precise set of what people/organizations who donate get back for their money. For example, precedence with support or visibility on KERI conferences.
- TRGT11 - Improve and maintain the open-source code base
> We maintain:
- the code in [WebofTrust github.com](https://github.com/weboftrust)
- the standardization documents in [TrustoverIP github.com](https://github.com/trustoverip)
> We adapt to:
- the [TrustoverIP.org Model](https://trustoverip.org/toip-model/)

## Operational plan
To do:
- TRGT12 - create the foundation's Development Reference Implementation Working Group
- TRGT13 - Issue bounties from the web-of-trust GitHub repo as an organization. One of the fastest paths to tooling.
- TRGT 14 - Choose the domicile and set up the foundation - get an address and a bank account
- GOAL6 - Create and maintain commercial services delivered by the foundation:
- Consultancy
- Donations
- Kick-back fees
- Minimal Viable Products

#### Derived secondary to do's
-TRGT15 - Roadmap: explain the design choices (ongoing)
- TRGT16 - Structure the all-encompassing foundation internationally
- Bounties could offer a good testbed for - and selection of programmers
- How about finding the right person to code first? We might know people we want to work with. Lead developers could do the intake, and then after we have a tentative agreement in progress, we could promote their capabilities and try to find the resources for the task. E.g., "One-click KERI is only XX,XXX $ away. PPPPPP is eager to accept the assignment, but we must first consolidate the budget. Check out our donation tiers <here>"
We could gradually lift the confidentiality of the deal or the developer's privacy only for those interested in donating money to this specific task or project.

### Find funding
Focussing on KERI-only projects or KERI-inspired projects, various types of donators to the foundation can be distinguished, those who:
1. Carry out their own projects, funded by a single main donator, spending those funds & (own) time
2. Spending funds on the open source codebase (not yet applicable)
3. Spend funds on hiring people to work on open source codebase (already happening)
4. Spend their own valuable time on the open source code base (already happening)

Donators to a foundation understand:
1. "1. Donations to the foundation do not confer any influence or control over its direction."
2. A foundation has a few interest groups competing over the application of resources.
3. Although there are rewards from a donation model in tiers, no revenue model stems from donation(s).

Donators willing to put some money (bullet 2. above) in a foundation will base their decisions on the prevention of the following situations occurring soon after putting their money in:
1. The foundation is controlled and owned by big corporations and people with their agenda
2. Some participants promise to put in money, but in the end, they don't
3. Rewards are meaningless
4. The foundation is being drained by officers receiving fees
5. The risk of the membership / being a donator exceeds the nominal amount of the donation.

Because of this and lessons learned elsewhere, we will take time to design a balanced decision-making structure, role-based and authority-based carefully. The Linux Foundation model, among others, could serve us as a good example.
We write the rules well upfront to avoid getting in too much trouble further down the road.

### Lead Role for the inventor
Like the example of the Linux Foundation, we should make rules and regulations so that KERI inventor Sam Smith can rule over the KERI Foundation like Linus Torvalds could - and still can - over Linux. It'll undoubtedly have changed over the years the Linux crew has been active.
The KERI foundation will do so, too, but let's start by putting Dr. Smith in the driver's seat.

Once the ethos around the KERI Suite has matured, his role could be more relaxed and less stringent.

#### Coopetive design

Sam Smith is quite a different type of expert than, for example, Linus Torvalds, Guido van Rossum or other initiators and coders of large open-source projects. Sam has always been a builder of systems at scale. Nothing is better than a real-life proof of your design, concepts, and standardizations.
This is why Sam has also been focussing on infrastructure for KERI. He saw that such infrastructure did not exist for secure identifier systems at scale.

##### Compatible solution for business-minded members of the foundation
To look for economic incentives to make web-scale infrastructure work for the new ideas he has (had), like the KERI Suite, is something Dr. Smith will continue to do. It keeps him sharp. The design of the foundation has to serve a method to be *coopetive*: the time to put in a business initiative has to healthily compete with the time put into taking up roles and executing tasks of the foundation. In other words, the foundation has to pay people in a market-conform manner.

The good thing is that the foundation will run as a role-based business, and these coopetive characteristics apply to every member of the foundation, not only Sam.

#### Two-way commitment | TBW |
There is another reason why the team should set up the foundation this way. Benevolent dictatorship for life (BDFL) is preferably a two-way commitment. In return for the foundation's commitment to Sam and the lifetime* role granted in the KERI foundation, we ask for Sam's commitment to the KERI foundation, too. This means:

{ Sam might put something here}

*As long as he wishes and as long as he is physically and mentally able to, hopefully, many years to come.

### Reduce complication
by: Sam Smith

In the following order, we reduce the complication that the newly invented KERI Suite introduced, along five consecutive W's:

1. Wallet - inception and further key management
2. Witness - promulgation of key state
3. Watchers - validation of authoritative key state
4. Web - infrastructure -> 3W leverage it -> API
5. Wizard - Guiderails & bumpers -> 10 page manual

Developers who examine the current complications of KERI ask themselves: Can I swiftly get a prototype up and running?

The construction of a community Minumum Viable Product, that the foundation offers as open source.

### Balanced and transparent decision-making process
If responsible roles are carved out (competence profiles), then anyone could apply to accept a position where tasks need to be accomplished to fulfill the objectives of the KERI foundation.

### Lean and mean setup
The foundation we create will have no employees on the payroll. It'll only have fees installed for roles of which this will be more or less the outflow of money:
- 60-80% developers of code
- 10% direct project management and staff tasks
- 5-10% overall management/accounting/reporting
- 5-20% marketing and educational resources costs

Of course, the largest share will go to developers. 60-80 %, but the actual figure depends on how much preparatory work is involved. A small team does the preparatory/project management work. The first donations will leverage other future contributions to an even higher percentage of the lump sum available for developers.
So, the more participants we get, the more likely the system will allow 80+ % of the donated money to be directly assigned to developers.

## Targets
1. One-click KERI up & running in one year.
2. KERI Suite is provably the most secure identifier system on earth.
3. {more}

## Principles
* Open source code development under Apache-II license
* Governance documents and educational resources under Creative Commons license |<-TBD|.
* "We're happy to receive your PRs."
* Contribute back when you use

## Timing
{TBW Planning/timing: How, what, actions: Strategic – tactical – operational.
Some matrix How->Low level versus Long term – urgent short term actions.
Group (1,2,3) -> Sub (1.a, 1.b, 1.c) -> Action (1.a.i, 1.a.ii, 1.a.iii)
}

## Questions and answers

- *Who's going to manage the code creation process once the money is there to hire the right coders?*
Sam Smith: "I would be happy to supervise any bounties. .. I am open to doing consulting work."

- *What would be the ideal coder right now?*
Competence profile of the programmers:
Start as a good coder 
Smart & learn quickly
Python  (a fan)
Full stack developers - must - the first one
English language proficiency
US Timezones 
Security (not OIDC, OAuth, blockchain)
Nice to have:
Cryptography expertise

- *How can we create a KERI foundation with the money gathered and the right objectives/legal backing?*
People might be willing to put some money into a foundation that will not be abused by the big corps and people with their agenda soon after. A sound financial paragraph of the "Tooling operation" is needed.

- *At how many FTEs are we currently looking (what do we need), and what's the time span for an operation like this?*
Sam Smith: "The ideal team would be around five developers, but even one or two in addition to me would be game-changing."

- *What kind of immaterial rewards can we give to donors to the foundation?*
Look at the [tiered donation model](#Tiers) below.

- *Why not have {some role} do {this or that} {there} to raise funds?!*
If you think you can raise a lot of money by putting someone there: go do it in a working group. If you cost more than you yield, your working group will be reshaped, but if you yield more than you cost, you are free to determine with that money what happens in the other working groups.
Your own role has to fit in the fee-structure of the foundation

- *Why can't we code whatever we want with directed funding?*
⁠If you want more freedom, you can, Sam/the responsible team/foundation may or may not certify your code. If you get off track with your code (insecure, a fork or whatever) then the foundation will label your working group as a company.
Security is the main selling point of the KERI Suite. The foundation is the image of this. The chain of all implementations together is as strong as the weakest link.
We can't have the reputation of the KERI Suite or the foundation put on the line because some group wants to code whether they like. They can, but not inside the foundation.

- *How to become an IRS-recognized charity outside of the US?*

For a charity based outside the US to become eligible for IRS-recognized tax-deductible donations, it generally needs to follow a specific set of procedures. The process usually involves establishing a relationship with the IRS through a recognized US affiliate or meeting specific criteria for tax-exempt status. Here’s a general overview of how foreign charities can become recognized by the IRS:

1. Establish a US-Based Affiliate or Partner
Most common method: Foreign charities often establish a US-based affiliate or partner organization that is recognized as a 501(c)(3) tax-exempt entity by the IRS. The US-based entity can then handle donations and ensure they are tax-deductible for US donors. Here’s how this typically works:

Form a US Non-Profit: Establish a separate nonprofit entity in the US that is registered as a 501(c)(3) organization.
Fundraising and Operations: The US-based affiliate can then solicit donations, which are tax-deductible for US donors. It can also fund and support the activities of the foreign charity.

2. Use a Fiscal Sponsorship
Alternative method: A foreign charity can partner with a US-based 501(c)(3) organization through fiscal sponsorship. The fiscal sponsor will handle the fundraising and tax-deductible donations on behalf of the foreign charity.

- Fiscal Sponsorship Agreement: Establish an agreement with a US-based fiscal sponsor that allows the foreign charity to receive tax-deductible donations indirectly.
- Compliance and Reporting: The fiscal sponsor will handle compliance with IRS regulations and provide the necessary documentation for US donors.

Steps for Foreign Charities to Follow:
- Consult with a Tax Advisor: Engage with a tax advisor or legal expert familiar with US tax law and international charitable organizations.
- Explore Partnerships: Consider establishing a US-based affiliate or partnering with an existing US nonprofit.
- Prepare Documentation: Ensure all necessary documentation and compliance measures are in place if pursuing direct IRS recognition.
- Apply for Tax-Exempt Status: If establishing a US-based entity, complete the Form 1023 application and meet all IRS requirements.
Resources and Contacts: IRS Website and Legal and Tax Professionals

The same situation applies to Switzerland. For Swiss donors to be tax-exempt it might be necessary to have - or work together with a Swiss-based affiliate.

## Positioning in the marketplace

We should position this open-source not-for-profit vehicle alongside and in cooperation with commercial entities and governmental/international umbrella organizations.
It has to be clear to all involved that the money you donate to a foundation may have inevitable spin-offs but, in general, does not have financial leverage nor gives donors ultimate power over the foundation. Conversely, commercial ventures can have all this. We can set up the foundation to achieve good harmony with future participating companies—any company, even backed by VCs.

We could design a way to motivate commercial projects to donate a share of their invoices to the foundation ([principle 4](#Principles)).

## History to be aware of
The relatively young KERI project has had its history with umbrella organizations. Needless to revisit the details, it is essential to share our lessons learned:
We can't allow any entity to try to hijack KERI's open-source status, development, and reputation.
We don't say somebody will; we say we won't let anyone get the chance to do so.

It's the founder's baby, KERI. He should be happy with every aspect of this new foundation. That's why we want to be cautious: when you allow people to roll out their agenda, they will.

Delegation of responsibilities and tasks is good after you've been able to create and install the rules upfront.

## The path forward

> "Keep out Dagobert"

The KERI inventor and the KERI core team first determine what the objectives of a Foundation should be:
- Which targets, principles, working methods, target groups, partners?
- A good framework in simple, everyday human language. Once completely clear, you determine which (administrative) organizational form and jurisdiction best suits this.
- It's *just a form or a structure* and we don't want a Foundation to come parenting over us or to hand over power to "the suits." Of course, we're not pointing fingers; we're just expressing some experience: we mean the people who know little about KERI, are late to the party and are especially politically engaged or interested in getting rich quickly. We'll try our best to refrain from engaging them with the foundation. For safety reasons, we'll have the tools to replace any unwanted factors inside the foundation.
- The Foundation's design needs to be scalable from scratch.

**Reminder**: This document is a plan that makes sense for the KERI inventor to think through and work out everything internally (with people he knows and trusts).

## The structure
**The Apache Foundation or the Linux Foundation model could serve as an example: autonomous cells under an umbrella.
What we could do is study these examples and choose the appropriate parts.**

flowchart TD
    D(KERI Foundation) <---> B(WG Swiss-ID)
    D <---> C(WG RUST stack)
    D <---> A(WG Implementations)
    D <---> E(WG Education)
    D <-.-> |"???? based "|D
    A <-.-> |"US-based"|A
    B <-.-> |"Swiss/? reputation"|B

**Mind you: Just an example!!**

### Common and Successful Setup for an Open-Source Software Foundation

A separate document in rough draft, inspired by the Linux, Pyhon, Apache, and Eclipse models. An appropriate structure needs to emerge over the coming months and be able to adapt to growth. Therefore, we need an in-depth broad discussion over the next few months. First, we want Sam in the driver's seat and get us a vehicle.

Apart from the role of the BDFL (Linux and Python Foundation model), we give way for various other initiatives in working groups, as long as initiators are willing to connect to the foundation, which could, for example, focus on the RUST implementation or another on Education. Prominent donors of money will be able to direct funds.

## Domicile
The foundation's domicile could be more than one. Preferably, we keep the community together and try to prevent competition over donors. Workgroups could easily find domicile anywhere. We use open-source software, so we're used to operating remotely and digitally. The domicile (s) of foundations and work groups are a result of the design process.

### Selection criteria
- cost and tax-efficient solution
- neutral and reputable image
- uncomplicated
- native English language in the jurisdiction at hand
- remotely manageable and US time zone friendly

#### Tax-exempt and tax deductibility
*Tax exempt* means an entity or natural person doesn't have to pay taxes in their jurisdiction, or you're a citizen over the gift you give to a charity with a particular domicile. We refer to *tax deduction* when a possible donor could deduct a gift to a charity from his taxable income.

As a foundation, we should offer as much tax exemption as possible to donors from the main donor countries, even if that means setting up a subsidiary of the foundation in those countries.

Tax deductibility is too hard for a foundation to achieve because of the variation in individual cases. However, we will offer general guidelines and advice to consult a tax specialist.

## Comparison of NPO Setup in Scotland, Switzerland, US, and Ireland
*DISCLAIMER: This is a draft generated from a chatGPT conversation. So look at the structure and creativity, but don't trust the data at face value. We've dived deeper into various aspects to check the validity of the content, but this is not yet reflected in these outputs*

### Detailed Comparison Table
## Comparison of NPO Setup in Scotland, Switzerland, US, and Ireland

### Detailed Comparison Table

| **Aspect** | **Scotland (USD)** | **Switzerland (USD)** | **US (USD)** | **Ireland (USD)** |
|-----------------------------|-------------------------------------------|--------------------------------------------|------------------------------------------|------------------------------------------|
| **Setup Costs** | $700-1,500 | $6,600-13,200 | $2,000-5,000 | $1,100-3,300 |
| **Annual Compliance Costs** | $1,000-3,000 | $3,300-5,500 | $1,500-5,000 | $1,100-3,300 |
| **Tax Exemption for NPOs** | Yes | Yes | Yes | Yes |
| **Donor Tax Benefits** | Gift Aid (25% increase) | Up to 20% of net income | Deductible within limits | Deductible within limits |
| **Reporting Requirements** | Annual accounts and reports | Annual financial statements | Annual financial statements and Form 990 | Annual financial statements |
| **Audit Costs** | $5,000-10,000 | $5,500-11,000 | $5,000-10,000 | $3,300-7,700 |
| **Reputation** | High | High | High | Moderate |
| **Regulatory Complexity** | Moderate | High | High | Moderate |
| **Operational Flexibility** | High | Moderate | Moderate | High |
| **Digital Infrastructure** | High | Moderate | Moderate | High |

### Summary of Specific Pros and Cons for Each Country

#### **Scotland**

| **Aspect** | **Pros** | **Cons** |
|-----------------------------|------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------|
| **Reputation and Trust** | High level of trust and transparency in the UK charity sector. | Moderate regulatory complexity with multiple bodies (OSCR and HMRC). |
| **Tax Benefits** | The Gift Aid scheme provides a 25% increase in donation value. | Potentially higher audit costs compared to some other jurisdictions. |
| **Digital Infrastructure** | Strong digital infrastructure supporting virtual operations. | N/A |
| **Setup and Compliance Costs** | Relatively low setup costs and moderate compliance costs. | N/A |

#### **Switzerland**

| **Aspect** | **Pros** | **Cons** |
|-----------------------------|------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------|
| **Reputation and Trust** | High trust and credibility associated with Swiss foundations. | High setup and operational costs. |
| **Stability** | Stable political and economic environment. | Stringent regulatory requirements and potential need for audits depending on the canton. |
| **Tax Benefits** | Attractive tax exemptions for NPOs and tax-deductible donations. | Complex regulatory framework can be challenging to navigate. |

#### **US**

| **Aspect** | **Pros** | **Cons** |
|-----------------------------|------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------|
| **Donor Base** | Access to a large donor base and a strong culture of philanthropy. | Higher setup and compliance costs. |
| **Tax Exemption** | Clear tax-exempt status and well-established guidelines from the IRS. | Detailed annual reporting required through Form 990, which can be complex. |
| **Funding Opportunities** | Numerous funding opportunities from government, foundations, and individuals. | Complex and varied state regulations that may add to administrative burden. |

#### **Ireland**

| **Aspect** | **Pros** | **Cons** |
|-----------------------------|------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------|
| **EU Membership** | Full access to EU funding and grants. | Higher setup and operational costs. |
| **Tax Benefits** | Favorable tax regime and deductible donations. | Complex compliance requirements but manageable with strict business-like governance. |
| **Digital Infrastructure** | Developed digital infrastructure that supports virtual operations. | N/A |

### Summary

- **Scotland**: Offers a highly reputable and transparent environment with relatively low setup and compliance costs. Gift Aid provides significant tax benefits, making it an attractive option for donors.
- **Switzerland**: Provides high trust and stability with significant tax benefits, but it also has high costs and complex regulations.
- **US**: Known for a large donor base and explicit tax exemptions, but higher setup, compliance costs, and complex state regulations.
Ireland offers EU membership benefits, good digital infrastructure, and moderate costs but may have complex compliance requirements. Running the foundation with strict business-like governance can mitigate these issues.

## Funding of the Foundation

> "We are not looking for a generous uncle who donates something for the enthusiastic but naive niece."

### Donations to the Foundation deliver returns

The aim here is to deliver returns by delivering or supporting (minimally) viable applications. We offer an opportunity to become a stakeholder in a new development. We directly (application) or indirectly (knowledge) deliver more than the investment/contribution.
Interestingly enough, donors become partners or stakeholders with the characteristics of a client in this way.

They even become co-explorers with Stanley and Livingstone: not sponsors/donors, but trailblazers, pioneers, innovators—at least early adopters and frontrunners. That'll cost them money and time (just like a license for Mount Everest), but they get a lot in return—assumably even a strategic advantage.

> Example: Pay for priority
SaltStack -> custom feature -> first delivered to donator (competitve edge) -> generalized -> publicly available

### Sponsors
A scalable foundation cannot accept donations by offering the help of a programmer paid by organization XYZ, also referred to as "sponsoring in kind." This seems unproductive (why not accept any help?), but it's smart and forward-thinking to refrain from this type of sponsoring.

Sponsors in kind is a non-scaleable mechanism, which is also risky. We (the KERI foundation) seek added value within the objectives and projects the KERI inventor lays out under his control. We need more time to write the competence profiles, write the summaries and requirements of certain coding efforts, attach rewards to these positions, symbolically write these responsibilities at the back of some chairs, and then - and only then - see whether some sponsored developer "in kind" fits that chair. If not, we must keep looking for a fit for this particular chair, whereas a donator must look for suitable chairs that might match one of their available experts.

A model like that is scalable and less vulnerable to the characteristics of individual programmers and individual parties offering a programmer.

We need some time in this case, but the *One-Click KERI* project could guide the KERI foundation in implementing this structure.

### Tiers
*DISCLAIMER: This is a draft generated from a chatGPT conversation. So look at the structure and creativity, but don't trust the data at face value.*

#### Memberships
The Foundation offers four levels of membership: Strategic, Contributing, Associate, and Committer.

| Donation Tier | Annual Contribution | Benefits | Role/Influence in Foundation |
|------------------|---------------------|----------|------------------------------|
| **Committer** | $0 | - Listed as a supporter on the foundation’s website | - accepted PRs means integrated code |
| **Associate** | $10,000 - $99,999 | - Company logo on website and newsletters<br>- Mention in press releases<br>- Early access to updates<br>- Invitations to exclusive webinars and events<br>- Access to detailed progress reports and roadmaps<br>- Prominent logo placement<br>- Input on the development roadmap<br>- Custom training sessions for donator’s team<br>- Co-branded marketing opportunities |- Listed as a supporter on the foundation’s website<br>- Quarterly update calls with project leaders<br> - Advisory role with quarterly input on budget allocations<br>- Invitations to foundation strategy meetings |
| **Sponsoring** | $100,000 - $249,999 | - All Associate benefits<br>- Exclusive "Sponsoring Donator" recognition<br>- Priority access to beta testing<br>- Dedicated support from the KERI team<br>- Opportunity to host joint events | - Voting rights on key budget decisions (up to 10% influence)<br>- Annual review meetings with foundation executives |
| **Strategic** | $250,000+ | - All Contributing benefits<br>- Exclusive "Strategic Donator" recognition<br>- Direct collaboration on specific features<br>- In-depth consultancy<br>- Top logo placement | - Significant voting rights on budget decisions (up to 25% influence)<br>- Seat on the foundation's board of directors |

#### Sponsorship Individual

The Foundation offers flexible sponsorships.

The KERI Suite is the leading open source platform for professional developers in secure Autonomous Identitfier Systems, handling millions of identifiers every day. The Suite is 100% free and open source.

By contributing, you'll help ensure it stays that way and contribute toward its future development.

##### Invest Your Time
Help answer questions rather than just asking them. Share your knowledge, experience, and expertise.

Help fix bugs and help implement enhancements rather than just reporting problems and requesting features. Not only will you personally benefit, giving back to the commons makes everything better for everyone.


#### Corporate Sponsorship
The KERI Foundation relies on the support of our members and contributions from the user community to service and grow the KERI ecosystem. We’d like to thank the following Corporate Sponsors who have generously supported the Eclipse community.

We encourage large corporate users of KERI to support the community by becoming members and/or joining the Corporate Sponsorship Program.

#### Sponsor a collaboration
Support a working group, without committing to membership: you can become a sponsor. As a sponsor, you can donate on a one-time or recurring annual basis to support working group initiatives that matter to your organisation.

## Marketing

We want to place all KERI competitors in perspective of the key unique selling point of the KERI Suite: **security first**. In an as friendly manner as possible, we will point out the lack of security of competing identifier systems. Next, we're determined to expose (the lack of) scalability, (the lack of) versatility, and other secondary features and challenges.

We intend to supply the appropriate knowledge and argumentation.
1. Earlier, we were thinking of an attack vs. infra comparison table (which I generated initially using chatGPT). We have yet to be able to finish this.

2. Also, a feature comparison table would be great. E.g., Charles Lanahan commented recently on this: https://gist.github.com/jceb/8e37e4900e815eb14b207ad7e8d02a6c

3. We might have to repeatedly press the expert's responsibility button: "How could you work on—or work with—identifier systems that you knew were insecure to date?" (You knew because you were told over and over again!)

4. We could also work on busting the myth that KERI is complex.

How could we quickly produce public information about the drawbacks of other identifier solutions at three levels of understanding that are undisputed, a no-brainer for experts, and reasonable for outsiders?

## Vision KERI compared to Linux history

We've compared the early principles of a few succesfull open-source foundations; one in particular: the Linux foundation. We asked Sam Smith to comment on the analysis of how the principles and emergence of Linux and the Linux Foundation could be an example for the KERI Foundation and how Sam Smith would steer the operation.

But please keep in mind: we're not designing 'Sam foundation'. We're creating a scalable KERI foundation secured by Sam that reuses the lessons learned from the first years of well-known open-source software foundations like Linux, Python, Eclipse, etc.

For a detailed report of the interview results, see the separate [Addendum](https://hackmd.io/YaKaOkK3Twm_zBswSbqEzw).

## Organization and decision making

The objectives of the design of the foundation's organisation structure, secured by inventor Sam Smith, are:
1. Resilient against takeovers by specific narrowly focused interest groups or commercial interests.
2. The KERI Suite copyright should be available to explore what we can do with it for society and business.
3. [Coopetive](#Coopetive-design). Plus, discuss tolerance for copying/pasting. With kick-back fees, could this be acceptable? How do we proceed with this type of situation?
4. Copyright - mentality: Apache 2 is mostly law; however, because we must integrate commercial activities around KERI, we sometimes need to accept commercial protective licenses.
5. We should discourage free riders as much as possible and take measures to protect ourselves against them.
6. Stakeholders must recognize our BDFL because we're in the security space. Smith: "KERI implementors can't ignore the core team. KERI solves a complicated technical problem (more than Linux). There is no such thing as an opinion on security. It's either good or broken." Although we want to keep the community together as much as possible, we must focus on initiatives supporting our inventor.
7. We set up a business organizational structure based on Sam's vision. Sam will retain a central technical and strategic role until the organization matures enough to absorb his role (preferably gradually). After that, he will keep an important advisory role. At the moment, Sam's role is the most essential condition for KERI's conceptual and business success (as broadly as possible).
8. We focus on security first; donors to open-source code and investors will eventually come around.
9. The most crucial cell is development, where the inventor watches over the three aspects: 1. security, 2. reference code, 3. licenses and IP, and 4. fit of other programming languages on the former three.
10. We adopt the management style in the KERI development community in the foundation for security reasons: the leaders have a clear opinion and voice it publicly. Smith: "We offer clear guidance because we have a vision. We keep making choices and explain them to people involved." Being a control freak is a positive competence at this stage of KERI's development, as well as the security characteristics involved.

## Transition of BDFL role over time

The authority of Sam making the final decisions on code changes to the reference model, and the overall security architecture will remain intact.
For many decisions, however, we would like to see a consensus based approach, as is usual in foundations.

Some ideas to discuss:
1. Place all strategic decision-making authority and allocation of funds (transparent including option directive/non-directive) with the board (3 or 4 people). The BDFL is technically responsible and can veto everything.
2. Implementation, including working groups, is "decentralized" role and performance based. They can do their thing as long as they stay within the budgetary, technical visionary and performance limits.
3. The board is reappointed every 2 years. Probably 3 or 4 years is better by the way. Something like a (funders) council (as broad as possible so that no single interest group seizes power) should have a say in this.
4. Sam's role is slowly moving towards an advisory role. He can then also train a successor.