Indie Cardano Node

Plan and start the implementation of an independent implementation of the Cardano Protocol.

Developing software since the 90s. Experienced in web scale applications, jvm, linux, haskell, blockchain (2011) and in building tech teams

## Motivation
Having multiple implementations of the Cardano protocol that can work interchangeably and together to operate the mainnet has a multitude of upsides as discussed in "insight sharing"
https://cardano.ideascale.com/a/dtd/We-need-to-prove-that-development-of-the-Cardano-protocol-is-open-and-democratic/332998-48088
https://cardano.ideascale.com/a/dtd/Having-only-one-node-implementation-might-be-risky/332999-48088

We as the collective steering entity of Cardano's future must ensure that multiple implementations of the Cardano protocol get funded and receive continued funding to keep up with the research and development of IOG and the steering decisions of the community.

While this proposal appears similar to the 2nd-Layer Ouroboros Rust proposal, its scope is different. Funding the development of a second codebase of a full node is a large undertaking that needs to be a long term commitment. From my experience of leading large scale teams in software engineering such a development operation can easily have a burn rate of 700.000$ to 1.000.000$ per year. So it is important to define how you want to approach this long term project, how you intend to assemble and maintain the team and what the delivery will look like.

## Outputs

This proposal intends to create the following outputs:
1. A detailed plan on how to create a drop-in replacement to github.com/input-output-hk/cardano-node including tech stack, implementation methodology . This also includes documentation about how we will be implementing the whitepapers, CIPs and how we intend to produce high assurance code to standards equal to those of IOG.
2. The proposal of an initial team of developers to start this project or on how the proposer intends to recruit a team.
3. An analysis of which technology stacks make sense for the implementation. The tech stack options to be analyzed are:
a) Create a second Haskell implementation
b) Create an OCaml implementation
c) Create an implementation on the JVM (Kotlin & Frege hybrid could allow us to keep critical parts pure and property tested)