IO: Developer Experience Initiative
248 DReps voted · 94 with a rationale · 14 changed their vote · 4 re-voted unchanged
Open a row to read the rationale.
Changed votes: 11 to yes, 1 to no, 2 to abstain, together voting with 1.3B ₳ of voting power.
- Yes115.6K ₳No rationale
- Yes107.4K ₳No rationale
- Yes95.5K ₳No rationale
- No90.6K ₳Rationale
Governance Action Review [EN]
1. Introduction
The Developer Experience Initiative is a Treasury Withdrawal proposal requesting ₳3,601,926 to fund a focused six-month program led by Input Output’s Cardano Business Unit. The proposal aims to improve Cardano’s developer tooling, documentation, onboarding experience, and ecosystem coordination, with a stated target of achieving a 30%+ improvement in developer growth rate. Its stated objective is to help a builder new to Cardano move from zero to an MVP on testnet in under two weeks, reducing the initial time investment needed to validate Cardano as a platform choice.
The initiative includes workstreams such as community alignment, developer outreach, cardano-init, Developer HUB, ContractsLibrary, community collaboration, measurement through a hackathon, and reactive work addressing high-ROI DevX opportunities. The proposal identifies fragmented tooling, poor documentation, steep learning curve, subpar developer experience, and lack of ecosystem coordination as the main problems affecting Cardano developer adoption and retention.
The proposed funding distribution allocates ₳2,929,680, or 81%, to Development & Engineering teams, ₳432,231, or 12%, to Engagement & Ecosystem support, and smaller allocations to infrastructure, security and audits, legal and compliance, operations and delivery, governance, and other costs. The proposal also states that a written off-chain legal contract will be created between Input Output and Cardano Development Holdings, administered by Intersect, with milestone-based delivery, third-party assurance, treasury reserve smart contract management, refund conditions, and public reconciliation of unused funds.
2. Governance Action Analysis
Positive aspects
The proposal addresses a real and relevant problem for Cardano. Developer experience remains an important bottleneck in the ecosystem, especially for new builders trying to move from zero to a functional MVP on testnet without spending weeks navigating fragmented documentation, inconsistent tooling, and a steep learning curve. In that sense, the general objective of the initiative is legitimate: improving onboarding, tooling, documentation, reusable patterns, and coordination around developer experience.
The proposal structures this objective around deliverables such as cardano-init, Developer HUB, ContractsLibrary, community collaboration, outreach, and DevX measurement mechanisms. These are potentially useful deliverables, and the proposal identifies an important need within the ecosystem.
The proposal also mentions collaboration with Intersect, Cardano Foundation, TxPipe, and community members, and states that the Developer Portal will be the main entry point for developers. This is positive and reduces part of the concern around institutional concentration.
Negative aspects
Recognizing that the problem is real does not mean accepting that this is the best structure to solve it. The main concern remains the budget. For a ₳3,601,926 withdrawal in a program lasting only six months, the level of financial detail is insufficient.
The proposal provides an aggregated distribution, with 81% allocated to “Development & Engineering” and 12% to “Engagement & Ecosystem support,” along with smaller categories such as infrastructure, security, legal, governance, and operations. However, this structure does not allow a clear evaluation of which amounts fund which deliverables, how many people will be involved, which roles will be hired, which rates or FTEs were assumed, how much will be allocated to bounties, how much will remain with IO, how much may go to external partners, and how each portion connects to verifiable milestones.
This point alone is sufficient to justify a vote against. The larger the Treasury withdrawal, the greater the required budget granularity should be. A multi-million-ADA budget should not depend on broad categories that make it difficult to evaluate proportionality, efficiency, and lower-cost alternatives.
The issue is not to presume bad faith or deny the team’s technical capability. The issue is that DReps must decide on the allocation of public ecosystem resources based on verifiable information, not generic institutional trust. Trust is great for friendships, not Treasury budgeting.
The proposal also appears to underestimate the current economic context of the ecosystem. Improving DevX may reduce technical friction for new developers, but it does not answer the most important question by itself: what will those developers find after being onboarded? The ecosystem is currently facing greater financial restriction, with several projects shutting down, funding becoming scarcer, Catalyst in transition or absent as a broad funding mechanism, and intense competition for available Treasury resources.
In this context, the ability to attract new builders depends not only on documentation and tooling, but also on real funding opportunities, liquidity, sustainability, and clear paths for projects to survive after the initial stage.
There is also a relevant strategic tension. The proposal aims to make it easier for new developers to enter the ecosystem, but at the same time it represents another significant Treasury withdrawal by an already established entity, in a cycle where a large portion of available resources is already being disputed or absorbed by major initiatives and consolidated actors.
This creates a practical contradiction: improving the ecosystem’s entry point is positive, but if the resources that could sustain new projects become increasingly concentrated in large institutional programs, onboarding may become only a partial solution to a broader problem. Cardano may have a better developer experience, but that does not guarantee retention if the economic environment remains unattractive for new teams.
Risks and concerns
There is an institutional centralization risk. Developer experience is not merely a neutral technical layer. It influences which tools are seen as standard, which workflows are recommended, which examples new builders follow, which libraries gain traction, which patterns become canonical, and which actors gain more influence over the formation of the next generation of Cardano developers. For that reason, governance of this layer matters.
Although the proposal mentions collaboration with Intersect, Cardano Foundation, TxPipe, and community members, the general structure of the initiative remains strongly led by IO. For an area as sensitive as onboarding, documentation, tooling direction, and canonical developer experience, a more neutral, open, and community-led approach would be more appropriate. Cardano Foundation, Intersect, Tooling DAO, dOSPO/OMF, targeted bounty programs, and community initiatives could play this role with lower institutional concentration risk.
This should not be read as a criticism of IO’s technical competence. The issue is different: the more strategic functions remain under the direct influence of founding entities, the harder it becomes to develop a broad, decentralized, and competitive execution layer in the ecosystem. In many cases, community or independent teams could deliver relevant parts of this work at lower cost, with greater proximity to active builders and greater diversity of approaches.
In the long term, practical decentralization requires critical functions to be distributed, not merely coordinated by large incumbents.
There is also a coordination concern with other initiatives. Multiple programs and proposals relate to tooling, open source, documentation, developer support, and developer experience improvements. The proposal itself includes broad items such as “Community Alignment,” “Developer Outreach,” “Community Collaboration,” and “Reactive” work. These may be useful, but they also make the scope elastic and potentially overlapping.
An initiative of this size should present more clearly how it differs from other workstreams, which responsibilities belong to IO, which would be executed by partners or the community, which specific gaps are not covered by existing initiatives, and why a centralized six-month proposal is preferable to a combination of bounties, RFPs, smaller grants, and open coordination.
3. Vote and Rationale
Vote: NO
The problem is not the existence of a proposal for DevX. The problem is the form. The proposal has merits, identifies a real need, and includes potentially useful deliverables, but it does not provide a sufficiently detailed budget, does not convincingly address the economic context of contraction and scarce funding for new builders, and concentrates an overly strategic layer under IO’s leadership.
The budget concern is the primary decision point. For a ₳3,601,926 Treasury withdrawal over six months, the proposal does not provide enough financial granularity to evaluate proportionality, efficiency, staffing assumptions, allocation between internal and external work, bounty amounts, partner distribution, or the relationship between each budget portion and verifiable milestones.
The current economic context further weakens the case for approval. Improving onboarding and tooling can help developers start building, but it does not solve the funding, liquidity, sustainability, and retention problem that new teams will face after entering the ecosystem.
The institutional structure also raises concerns. Developer experience shapes canonical tooling, documentation, workflows, libraries, and developer norms. Concentrating this layer under the leadership of an already established founding entity increases the risk of institutional centralization, even if the team is technically competent and even if collaboration with other actors is included.
The vote could be reconsidered if a future version presented substantially greater budget granularity, clearer separation of responsibilities among IO, partners, and community actors, stronger justification for why this centralized structure is preferable to bounties, RFPs, or smaller grants, and a more convincing response to the current funding constraints faced by new builders.
4. Conclusion
Developer experience is a legitimate priority for Cardano, and the proposal identifies a real ecosystem bottleneck. However, the current structure does not provide sufficient budget transparency, does not adequately address the broader economic constraints affecting builder retention, and concentrates a strategic developer layer too heavily under IO leadership. For these reasons, the appropriate vote is NO.
Revisão de Ação de Governança [PT]
1. Introdução
A Developer Experience Initiative é uma proposta de Retirada do Tesouro que solicita ₳3.601.926 para financiar um programa focado de seis meses liderado pela Cardano Business Unit da Input Output. A proposta busca melhorar o tooling, a documentação, a experiência de onboarding de desenvolvedores e a coordenação do ecossistema Cardano, com uma meta declarada de alcançar uma melhoria de mais de 30% na taxa de crescimento de desenvolvedores. Seu objetivo declarado é permitir que um builder novo na Cardano saia do zero e chegue a um MVP em testnet em menos de duas semanas, reduzindo o investimento inicial de tempo necessário para validar a Cardano como plataforma. :contentReference[oaicite:3]{index=3}
A iniciativa inclui frentes como alinhamento comunitário, developer outreach, cardano-init, Developer HUB, ContractsLibrary, colaboração comunitária, medição por meio de hackathon e trabalho reativo sobre oportunidades de alto ROI em DevX. A proposta identifica tooling fragmentado, documentação ruim, curva de aprendizado elevada, experiência de desenvolvimento abaixo do ideal e falta de coordenação no ecossistema como os principais problemas que afetam a adoção e retenção de desenvolvedores na Cardano. :contentReference[oaicite:4]{index=4}
A distribuição de recursos proposta aloca ₳2.929.680, ou 81%, para equipes de Development & Engineering, ₳432.231, ou 12%, para Engagement & Ecosystem support, e valores menores para infraestrutura, segurança e auditorias, legal e compliance, operações e entrega, governança e outros custos. A proposta também afirma que será criado um contrato legal off-chain entre a Input Output e a Cardano Development Holdings, administrado pela Intersect, com entrega baseada em marcos, garantia por terceiro, gestão via Treasury Reserve Smart Contract, condições de reembolso e reconciliação pública de fundos não utilizados. :contentReference[oaicite:5]{index=5}
2. Análise da Ação de Governança
Aspectos positivos
A proposta endereça um problema real e relevante para a Cardano. A experiência de desenvolvedores ainda é um gargalo importante do ecossistema, especialmente para novos builders que tentam sair do zero e chegar a um MVP funcional em testnet sem precisar atravessar semanas de documentação fragmentada, tooling inconsistente e curva de aprendizado elevada. Nesse sentido, o objetivo geral da iniciativa é legítimo: melhorar onboarding, tooling, documentação, padrões reutilizáveis e coordenação em torno da experiência de desenvolvimento.
A proposta estrutura esse objetivo em torno de entregáveis como cardano-init, Developer HUB, ContractsLibrary, colaboração comunitária, outreach e mecanismos de medição de DevX. Esses entregáveis são potencialmente úteis, e a proposta identifica uma necessidade importante dentro do ecossistema.
A proposta também menciona colaboração com Intersect, Cardano Foundation, TxPipe e membros da comunidade, e afirma que o Developer Portal será o ponto principal de entrada para desenvolvedores. Esse é um ponto positivo e reduz parte da preocupação com concentração institucional.
Aspectos negativos
Reconhecer que o problema é real não significa aceitar que esta seja a melhor estrutura para resolvê-lo. A principal preocupação continua sendo o orçamento. Para uma retirada de ₳3.601.926 em um programa de apenas seis meses, o nível de detalhamento financeiro é insuficiente.
A proposta informa uma distribuição agregada, com 81% para “Development & Engineering” e 12% para “Engagement & Ecosystem support”, além de categorias menores como infraestrutura, segurança, legal, governança e operações. Porém, essa estrutura não permite avaliar com clareza quais valores financiam quais entregáveis, quantas pessoas estarão envolvidas, quais funções serão contratadas, quais taxas ou FTEs foram assumidos, quanto será destinado a bounties, quanto ficará com IO, quanto poderá ir para parceiros externos, e como cada parcela se conecta a marcos verificáveis.
Esse ponto, por si só, já é suficiente para justificar um voto contrário. Quanto maior o saque do Tesouro, maior deve ser a granularidade exigida. Um orçamento multi-milionário não deveria depender de categorias amplas que dificultam a avaliação de proporcionalidade, eficiência e alternativas de menor custo.
A questão não é presumir má-fé ou negar a capacidade técnica da equipe. A questão é que DReps precisam decidir sobre alocação de recursos públicos do ecossistema com base em informações verificáveis, não em confiança institucional genérica. Confiança é ótimo para amizades, não para orçamento de Tesouro.
A proposta também parece subestimar o contexto econômico atual do ecossistema. Melhorar DevX pode reduzir a fricção técnica para novos desenvolvedores, mas isso não resolve sozinho a pergunta mais importante: o que esses desenvolvedores encontrarão depois de onboardados? O ecossistema está em um período de maior restrição financeira, com vários projetos fechando, funding mais escasso, Catalyst em transição ou ausente como mecanismo amplo de financiamento, e uma disputa intensa pelos recursos disponíveis no Tesouro.
Nesse cenário, a capacidade de atrair novos builders depende não apenas de documentação e tooling, mas também de oportunidades reais de financiamento, liquidez, sustentabilidade e caminhos claros para que projetos sobrevivam depois da fase inicial.
Há também uma tensão estratégica relevante. A proposta pretende facilitar a entrada de novos desenvolvedores no ecossistema, mas ao mesmo tempo representa mais uma retirada significativa do Tesouro por uma entidade já estabelecida, em um ciclo no qual boa parte dos recursos disponíveis já está sendo disputada ou absorvida por grandes iniciativas e atores consolidados.
Isso cria uma contradição prática: melhorar a porta de entrada do ecossistema é positivo, mas se os recursos que poderiam sustentar novos projetos forem cada vez mais concentrados em grandes programas institucionais, o onboarding pode se tornar apenas uma solução parcial para um problema mais amplo. A Cardano pode ter uma experiência de desenvolvimento melhor, mas isso não garante retenção se o ambiente econômico continuar pouco convidativo para novos times.
Riscos e preocupações
Existe um risco institucional de centralização. A experiência de desenvolvedor não é apenas uma camada técnica neutra. Ela influencia quais ferramentas são vistas como padrão, quais fluxos de trabalho são recomendados, quais exemplos os novos builders seguem, quais bibliotecas ganham tração, quais padrões se tornam canônicos e quais atores passam a ter maior influência sobre a formação da próxima geração de desenvolvedores Cardano. Por isso, a governança dessa camada importa.
Embora a proposta mencione colaboração com Intersect, Cardano Foundation, TxPipe e membros da comunidade, a estrutura geral da iniciativa permanece fortemente liderada por IO. Para uma área tão sensível quanto onboarding, documentação, tooling direction e experiência canônica de desenvolvedor, uma abordagem mais neutra, aberta e comunitária parece mais adequada. Cardano Foundation, Intersect, Tooling DAO, dOSPO/OMF, programas de bounties direcionados e iniciativas comunitárias poderiam exercer esse papel com menor risco de concentração institucional.
Esse ponto não deve ser lido como uma crítica à competência técnica da IO. A questão é outra: quanto mais funções estratégicas permanecem sob influência direta das entidades fundadoras, mais difícil se torna desenvolver uma camada ampla, descentralizada e competitiva de execução no ecossistema. Em muitos casos, equipes comunitárias ou independentes poderiam entregar partes relevantes desse trabalho com menor custo, maior proximidade com builders ativos e maior diversidade de abordagens.
A longo prazo, a descentralização prática exige que funções críticas sejam distribuídas, não apenas coordenadas por grandes incumbentes.
Também existe uma preocupação de coordenação com outras iniciativas. Há múltiplos programas e propostas relacionados a tooling, open source, documentação, developer support e melhoria da experiência de desenvolvedores. A própria proposta inclui itens amplos como “Community Alignment”, “Developer Outreach”, “Community Collaboration” e trabalho “Reactive”. Esses itens podem ser úteis, mas também tornam o escopo elástico e potencialmente sobreposto.
Uma iniciativa desse porte deveria apresentar com mais clareza como se diferencia de outras frentes, quais responsabilidades pertencem a IO, quais seriam executadas por parceiros ou comunidade, quais lacunas específicas não estão cobertas por iniciativas existentes, e por que uma proposta centralizada de seis meses é preferível a uma combinação de bounties, RFPs, grants menores e coordenação aberta.
3. Voto e Justificativa
Voto: NÃO
O problema não é a existência de uma proposta para DevX. O problema é a forma. A proposta tem méritos, identifica uma necessidade real e inclui entregáveis potencialmente úteis, mas não oferece orçamento suficientemente detalhado, não enfrenta de modo convincente o contexto econômico de retração e escassez de funding para novos builders, e concentra uma camada estratégica demais sob a liderança de IO.
A preocupação orçamentária é o principal ponto decisório. Para uma retirada de ₳3.601.926 do Tesouro ao longo de seis meses,
- Yes90.2K ₳No rationale
- Yes85.7K ₳No rationale
- No83.9K ₳Rationale
I am voting against the Developer Experience Initiative at this time. While developer onboarding is important, Cardano is currently in a critical infrastructure growth phase where resources must be prioritized toward the features that make our network distinct: high assurance, formal verification, and high security.
Advanced builders and enterprise partners are more concerned with throughput, security guarantees, and uptime than they are with simplified UI/UX tools.
I believe this initiative is mistimed. The treasury should remain focused on the vital technical upgrades required to scale the network and prove its security guarantees. - Yes65.9K ₳No rationale
- Yes63.1K ₳Rationale
I vote YES with accountability expectations. Cardano needs convenience without dependency. This proposal can reduce developer friction through shared tooling, better onboarding, reusable contracts, bounties, and measurement — all of which can strengthen ecosystem capacity if delivered openly and collaboratively.
My support is based on the expectation that the work is upstreamed where possible, coordinated with existing maintainers, transparently reported, and measured against real DevX outcomes. Treasury funding should not create permanent dependence on IO or any single provider. It should make Cardano easier to build on while increasing the capacity of the whole ecosystem. - Yes63.1K ₳No rationale
- Yes59.8K ₳No rationale
- Yes56.4K ₳Rationale
I shall continue to vote in favor of the Input Output Global (iOG formerly known as iOHK) proposals due to the fact that iOG has continuously year in and year out built, upgraded, innovated, and further strengthened the ecosystem through various market upheavals, negative press, and technological shifts. Through continuous efforts this cadre of developers, educators, various business persons, scientists, and experts in their fields have proven more than capable of the continued maintenance and innovation necessary to further the Cardano blackchain. I find value in all proposals from iOG until a suitable development group or lab can prove not only innovative, but evolutionary for the technology in which we all utilize and enjoy. The blockchain has survived based off of the creators of the protocol, we must continue the path set forth until we have a suitable substitute that can create viable upgrades and are capable of pushing the community and the blockchain into a realm of technological dominance I vote Yes for this proposal.
LourdeOuroborus Imperator Aeternalis - Yes55.1K ₳No rationale
- Yes51.8K ₳No rationale
- Yes50K ₳No rationale
- No48K ₳No rationale
- Abstain45.3K ₳No rationale
- Yes40.6K ₳No rationale
- Yes39.8K ₳No rationale
- No36.9K ₳Rationale
Why is an additional ₳3 million being requested now for Developer Experience when we already voted for ₳130,708,860 before?
Was this not included in the original ₳131 million budget? Also, only ₳78 million has been used so far, so why is more funding needed now?
- Yes32K ₳No rationale
- Yes29.3K ₳No rationale
- Yes28.8K ₳No rationale
- No26.7K ₳Rationale
It will fail if done with Intersect. No.
- No19.4K ₳No rationale
- Yes16K ₳No rationale
- Yes15.7K ₳No rationale
- YesRevoted15.3K ₳History
Earlier votes
Yes4mo agoSuperseded
- Yes14.8K ₳Rationale
I believe that io has the best interest of the cardano blockchain at heart.
- Yes11.4K ₳No rationale
- Yes9K ₳No rationale
- No6.8K ₳No rationale
- Yes4.1K ₳No rationale
- Yes3.6K ₳No rationale
- Yes2.4K ₳No rationale
- Yes1.7K ₳No rationale
- Yes1.2K ₳No rationale
- Yes1.2K ₳No rationale
- Yes999.7 ₳No rationale
- Yes688.8 ₳No rationale
- Yes684.6 ₳No rationale
- Yes84.1 ₳No rationale
- Yes10.8 ₳No rationale
- Yes0 ₳No rationale
- Yes0 ₳No rationale
- Yes0 ₳No rationale
- Yes0 ₳Rationale
I am voting YES on the IO: Developer Experience Initiative.
This proposal stands out because it draws strong attention to new opportunities in the ecosystem. Cardano already has a robust and secure infrastructure, but it was missing exactly this kind of practical incentive to attract and retain more developers.
With the proposed improvements — such as the cardano-init CLI, the OpenZeppelin-style smart contracts library, the unified Developer HUB, and bounties for existing tools — many new developers will be encouraged to join the network. These developers will build high-quality dApps, bringing more liquidity, more users, and real activity to Cardano.
This is a smart investment that accelerates the ecosystem flywheel and is fully aligned with Cardano’s 2030 goals for Adoption & Utility. The requested amount is reasonable, the management through Intersect is transparent, and the potential return for the network is significant." - Yes0 ₳No rationale