The Cardano Tooling Collaboration Pledge
A shared intention to build together, not in parallel
Why this pledge exists
Cardano tooling builders across the ecosystem solve the same problems again and again, and the cost falls on both the ecosystem and the developer trying to ship their first application.
Every hour spent rebuilding a transaction builder, a serialization library, or an onboarding guide that already exists elsewhere is an hour not spent making Cardano easier to build on. At the same time, many developers struggle to build on Cardano, to the point of abandoning the ecosystem altogether.
This pledge is an invitation to stop paying that tax. We can fix it by working together as one community.
The problem
When many teams each maintain their own version of the same primitive, the ecosystem pays for it several times over. The same work gets rewritten, the same bugs get reintroduced, and newcomers face a scattered landscape with no obvious starting point.
Developers have been telling us, directly and indirectly, year after year, that one of their clearest pain points is a fragmented, hard-to-navigate, hard-to-use, and under-resourced developer ecosystem.
Other ecosystems have faced this and chosen coordination. Editors and language communities once rebuilt the same integrations again and again, until a shared protocol turned a multiplying problem into an additive one: build to the standard once, and every compliant tool benefits. Two rival observability projects once competed for the same users until their maintainers merged into a single effort and treated it as the next version of both, with bridges in place so nobody was stranded. The lesson each time is the same. Fragmentation hurts everyone, and the unified result was better than either side could have achieved alone.
We can make the same choice.
What we ask, and what we do not
We ask builders to collaborate on shared foundations: the interfaces, formats, primitives, and documentation that every application depends on.
We do not ask anyone to stop competing. Healthy ecosystems need both. Collaborate on the foundations, compete on the products built on top. A shared standard for how tools interoperate takes nothing away from the team that builds the best wallet, the fastest indexer, or the clearest SDK.
Our principles
- Build on what exists: Before starting something new, we look for what we can contribute to instead.
- Interoperate by default: We adopt shared interfaces and data formats so that tools compose rather than collide.
- Openness: What we build for the shared foundation is open source, documented, and available to everyone.
- Room to innovate: Alignment is not uniformity. We coordinate on foundations and leave every team free to experiment above them.
- Evidence over opinion: We let developer feedback and ecosystem data decide what we work on first.
What we pledge
Builders who take this pledge aim, wherever they can, to:
- Check before you build: When a capability already exists and can be improved, we contribute upstream rather than starting a parallel copy.
- Compose, do not collide: We support the shared interfaces and formats so our tools work together out of the box.
- Declare compatibility openly: We publish our versions, dependencies, and compatibility so others can build on us with confidence.
- Share what we learn: Documentation, examples, and hard-won fixes belong to the whole ecosystem.
What we're aligning around
Good intentions need a shared direction. This pledge lines the ecosystem up behind one developer experience strategy, so our separate efforts add up instead of scattering. In practice, we pull toward:
- One front door: A single, canonical starting point for new developers, so nobody has to guess where to begin.
- A fast start on any stack: Zero to a working project in minutes, whatever tools a developer prefers, with improvements pushed back upstream to the tools themselves.
- Reusable building blocks: Shared, ready-to-use libraries and components that teams build on instead of rewriting from scratch.
- Documentation that stays current: Consolidated, maintained learning paths and documentation that both people and coding assistants can rely on.
- A shared map of the landscape: A living view of who is building what, so contributions fit together and the gaps are obvious.
How collaboration is rewarded
Collaboration has to pay, or it will not last. We reward it in more than one way:
- Direct funding to maintainers: Funding flows as bounties and support paid directly to the people and teams doing the shared, high-impact work, targeted at the problems developers hit most.
- Visibility on merit: Tools that developers actually use get surfaced at the point of onboarding, so quality and reliability are what earn attention.
- Recognition: We credit the maintainers whose work quietly holds the ecosystem up.
A working document
This pledge guides how we collaborate during the Developer Experience initiative led by Input Output Global (IOG). IOG stewards it as part of that work, and helps fund the shared effort it describes.
It is a living draft, not a rulebook, and no formal governance sits behind it. We hope we'll improve it as the initiative progresses and as builders weigh in.
Join us
If you build tooling on Cardano, you are already part of this. Taking the pledge means agreeing to a simple idea: we go further building on each other's work than we ever will building around it.
Let's build the developer experience Cardano deserves, together.
This is a working draft. Comments, objections, and proposed changes are welcome and expected.
Signatures
| Person | Team/Position - Organization |
|---|---|
| Robertino Martinez | DevX Lead - Input Output Global |
To sign, either add yourself directly by editing this file or comment on this issue and we'll add you.