IO: Developer Experience Initiative
248 DReps voted · 86 with a rationale
Open a row to read the rationale.
- Yes 21.1M ₳ No rationale
- Yes 20.3M ₳ No rationale
- Yes 19.9M ₳ Rationale
We need more builders on Cardano, the more builders we have the more likely one will build the killer app to drive up adoption. Partnering with Intersect and TxPipe on this makes a lot of sense to boost the developer onboarding experience.
- Yes 17.1M ₳ Rationale
IO: Developer Experience Initiative
- No 16.7M ₳ Rationale
I agree with the proposed outcomes, but the proposal doesn’t justify ₳3.6 million ADA for a 6-month program with a cost model that is still too coarse for a multi-million-ADA withdrawal. The accountability and cost traceability are not at the level we should demand: the proposal provides a top-level funding distribution (e.g., 81% “Development & Engineering,” 12% “Engagement & Ecosystem support”) yet it does not explicitly map those costs to named roles, FTE counts, rates, and milestone acceptance artifacts, which makes it hard to evaluate whether the same outcomes could be delivered for materially less. It also contains deliverables whose “definition of done” can be subjective (“contracts ready-to-audit,” “unified onboarding,” “improve NPS/DevX”) unless paired with concrete evidence requirements and measurement methodology at milestone boundaries. Finally, we are giving a process penalty for bypassing the Intersect Budget Process, which was specifically designed to address the gap in the process between proposers and Dreps. Proposals of this category are exactly where a disciplined budget mechanism and/or RFP-style selection should be used to compare competing approaches; bypassing that weakens price discovery, and founding entities should model the standard we expect others to follow.
- No 16.4M ₳ Rationale
IO has been funded by a significant amount of premine tokens.
- Yes 14.2M ₳ No rationale
- Yes 14.1M ₳ No rationale
- Abstain 13.3M ₳ Rationale
After carefully reviewing the proposal, associated documentation, community feedback, and its alignment with Cardano’s long-term strategic needs, I have decided to ABSTAIN on the IO: Developer Experience Initiative Treasury Withdrawal.
Let me begin by acknowledging that I strongly agree with the core problem this proposal seeks to address. Developer experience remains one of Cardano’s most significant barriers to growth and adoption. Fragmented tooling, inconsistent onboarding pathways, scattered documentation, and a steep learning curve continue to make it harder for developers to build effectively on Cardano compared to competing ecosystems. If Cardano is serious about long-term utility, developer adoption must improve.
There are many aspects of this proposal that I find encouraging. The focus on practical deliverables such as the cardano-init setup tool, an OpenZeppelin-style smart contract library, and a more unified Developer Portal onboarding experience addresses real friction points that developers frequently raise. I also appreciate the proposal’s ecosystem-oriented approach. Rather than operating purely as an internal initiative, it seeks collaboration with community maintainers, ecosystem tooling teams, Intersect, and external contributors, while including a bounty mechanism to support high-impact improvements across existing projects. This collaborative approach aligns with Cardano’s decentralised ethos and increases the likelihood that outcomes extend beyond a single organisation.
Structurally, this proposal is also more mature than many Treasury requests we have seen in the past. The inclusion of milestone-based disbursement, independent assurance, administrator designation through Intersect, refund provisions for unspent funds, and auditable treasury smart contract controls demonstrates a stronger commitment to accountability and constitutional compliance than earlier funding requests.
That said, despite recognising the value and intent of this initiative, I am not yet fully convinced that the governance and accountability framework is sufficiently mature to justify an unqualified Yes vote.
My primary concern relates to cost transparency and accountability. While the proposal outlines high-level budget categories, it does not provide enough detail regarding staffing assumptions, resource allocation, milestone cost attribution, or expected delivery effort to comfortably evaluate whether the requested ₳3.6M ADA represents the most efficient use of Treasury funds.
I also have reservations around the proposed success metrics, particularly the ambition of achieving a 30%+ acceleration in developer growth. While aspirational targets are valuable, developer growth is influenced by many external factors and should not be reduced to a single headline KPI. Instead, I believe milestone reporting should provide publicly verifiable evidence of meaningful progress — such as onboarding improvements, tooling adoption, upstream ecosystem contributions, and measurable reductions in developer friction.
Additionally, I believe there remains a legitimate governance discussion regarding process and precedent. As Cardano matures its Treasury governance framework, consistency in how large funding initiatives are proposed, compared, and evaluated becomes increasingly important.
My abstention should not be interpreted as opposition to improving developer experience — quite the opposite. I believe investment in developer onboarding, tooling, and ecosystem coordination is essential to Cardano’s future success. Rather, this abstention reflects a desire to encourage stronger standards of transparency, clearer budget accountability, and more measurable reporting as Treasury governance continues to mature.
RCADA remains open to revisiting this position should clearer cost traceability, transparent reporting, and publicly verifiable evidence of delivery be demonstrated either through future iterations or delivery evidence over time.
RCADA's full vote assessment can be found here: "https://brolloks.github.io/rcada-drep-votes/."
- Abstain 12.8M ₳ Rationale
I am voting ABSTAIN on governance action 73e171a4c0730b4b59ecae271ab89f12a9d56360b02920e1f95107dbdc1d6762#0.
Initially, I planned to vote No on this proposal.
Historically, IO's particular expertise has not been aligned with developer experience. Organizationally, they do fantastically robust engineering, but produce terrible user and developer experiences. This is not a criticism of IO: no organization can do it all. But if you look at their track record with Plutus, cardano-cli, breaking API changes, the PAB, etc. it is clear that having the people who build the core infrastructure also build the tools needed by the layer above them is a failing premise.
I believe that the proposal as written suffers from xkcd/927, it overlooks existing tools, built by companies already trying to solve these problems, convinced that this time will be different.
I would be much more supportive of a proposal that focused on:
- Hackathons, which historically IO has done well at organizing
- Providing assistance to existing tools, through engineers and deeper integration with infrastructure tools (as is already happening with UTXO RPC support in the node)
- Giving existing tools Discoverability and Legitimacy with an official endorsement
as I believe this would be a far more effective and higher leverage way to improve the developer experience for Cardano.
However, after discussing with the project manager assigned to this proposal, Robertino Martinez, I have decided to vote abstain instead.
It is clear that Robertino has a better perspective on this than his proposal implied, and he was receptive to my feedback. So while I can't vote on this proposal as is, I also wouldn't be heartbroken if it passed, as I believe Robertino could steer it in effective directions.
If the proposal fails, as seems the current trend, I would strongly support a revised proposal that focused on amplifying existing efforts.
You can find a larger writeup justifying my vote here.
- Yes 12.2M ₳ Rationale
As a longstanding DRep, we believe that this initiative addresses one of the most persistent structural weaknesses within the Cardano ecosystem: developer experience. While Cardano has developed strong underlying infrastructure and research foundations, onboarding friction, fragmented tooling, inconsistent documentation, and the absence of standardized development pathways have continued to slow ecosystem growth and developer retention. This proposal directly targets those bottlenecks through practical ecosystem-wide interventions including improved onboarding flows, unified documentation, reusable smart contract libraries, developer tooling, and coordination across existing contributors.
We acknowledge that some projected outcomes: particularly the targeted acceleration in developer growth; are ambitious and cannot be guaranteed within the proposed timeline. However, we view the core deliverables themselves as strategically valuable regardless of whether every ecosystem KPI is immediately achieved. Investments into developer infrastructure are long-term ecosystem multipliers whose benefits compound over time through reduced friction, faster deployment cycles, stronger standards, and improved accessibility for new builders entering Cardano.
We also recognize that the proposed budget is substantial. Nevertheless, after reviewing the funding distribution and implementation scope, we believe the allocation is largely justified by the engineering-heavy nature of the initiative and the breadth of work being undertaken. The proposal is not without execution risk, particularly around ecosystem coordination and adoption, but we believe the potential upside to Cardano’s long-term competitiveness outweighs those concerns.
- Yes 11M ₳ No rationale
- No 10.8M ₳ No rationale
- No 10.5M ₳ Rationale
Developer experience, onboarding, and documentation are important. They absolutely matter and I fully agree Cardano needs to make it easier for builders to get from zero to MVP faster.
I voted no because I do not believe spending ₳3.6M is a proportionate, disciplined or well-structured response to the actual problem.
The proposal frames the issue as fragmented documentation, tooling friction, weak onboarding and lack of coordination. But the uncomfortable truth is this:
A large part of the fragmentation being described is self-inflicted and much of it comes from IOG's own publishing habits. We already have:
developers.cardano.org maintained by the Cardano Foundation
And if we are being honest, the strongest evidence in this discussion points to the fragmentation being driven not by some mysterious ecosystem wide failure but by IOG itself publishing across too many places, with too little consolidation.
They keep docs on docs.cardano.org which is widely seen as under-maintained. They spin up Blueprint sections which then stall, not necessarily because of bad intent but because key people get pulled into other priorities and time becomes limited. Then instead of completing the agnostic version in the shared documentation flow, fresh technical specs get published as separate PDFs on Intersect subdomains.
Even when an IOG team lead does the right thing and puts important documentation like the new Tracer docs into the CF Developer Portal, other teams continue creating new locations. That is the fragmentation.
So before asking Treasury for millions more, the first question should be:
- Why hasn't this already been consolidated into one clear, neutral, community open source of truth?
Onboarding and dev experience absolutely matter - no disagreement there. But if the main sources of scattered and outdated information are coming from one org’s uncoordinated output, then the fastest and most rational way to improve things is not a large new Treasury ask.
The fastest fix is - better internal coordination + routing everything toward the one neutral, community open hub.
Because it is not asking Treasury to solve some entirely external problem. It is, in part, asking Treasury to pay millions to help fix a documentation and onboarding situation that IOG itself has meaningfully contributed to creating.
All other development proposals should already come with proper documentation. That should not be some optional extra or future clean-up item. If Treasury is funding work across the ecosystem, documentation should already be part of delivery standards and that documentation should already be pushed toward the Developer Portal managed by CF as the neutral entry point.
The good news is that this is actually fixable in a pretty straightforward way without needing a big new parallel effort. A more rational approach would have been -
fully back developers.cardano.org as the single source of truth- redirect or shut down overlapping documentation sites
- require IOG teams to publish there by default instead of opening new subdomains or standalone PDF flows
- add targeted bounties only for the highest-value missing gaps
And there is a bigger principle here - Treasury should not be used to pay millions to solve problems that were, at least in meaningful part, created by a lack of internal coordination from the same entities now proposing the solution.
IOG and CF are here to work on Cardano. There should be no other priority than making Cardano easier to build on.
If documentation is fragmented because teams keep publishing in fragmented ways, then the first step is not a multi-million $ADA proposal.
So do we really need to spend ₳3.6 million $ADA to solve this problem?
Or can IOG simply start practicing proper organization of documentation, proper consolidation of outputs and proper support for the Developer Portal that already exists?
For me, the answer is obvious. That is why I voted NO.
- No 9.6M ₳ No rationale
- Yes 8.8M ₳ Rationale
私は、この提案に賛成します。Cardanoの長期的な成長には、開発者体験（DevX）の改善と新規開発者の参入促進が不可欠であり、本提案はその課題に対して具体的な方向性を示していると考えます。特に、Developer Portal、cardano-init、Contracts Library、コミュニティ連携など、実装を伴う成果物が明示されており、単なる理念ではなく、実行計画として整理されています。成果指標には一定の不確実性が存在するものの、Cardanoエコシステム全体の開発者基盤強化は短期・中長期の双方において重要であり、本提案には一定の妥当性があると考えます。\n\nI support this proposal. I believe that improving the developer experience (DevX) and increasing developer onboarding are essential for Cardano’s long-term growth, and that this proposal presents a concrete direction for addressing those challenges. In particular, deliverables such as the Developer Portal, cardano-init, Contracts Library, and community collaboration are clearly defined, demonstrating that this is not merely a conceptual vision, but a structured execution plan. While there is some uncertainty regarding the projected KPIs and measurable outcomes, strengthening the developer foundation of the Cardano ecosystem is important from both short-term and medium-to-long-term perspectives, and I believe this proposal represents a reasonable direction for the ecosystem.
- Yes 8.1M ₳ No rationale
- Yes 7.8M ₳ No rationale
- No 7.8M ₳ No rationale
- Yes 7.3M ₳ No rationale
- Yes 7.1M ₳ Rationale
Changing my Abstain vote to YES
I am changing my Abstain vote to a YES vote. The team behind this proposal has addressed most of my concerns from my rationale and I think they not only identify a real chokepoint for Cardano - based on feedback received from developer surveys - but they also have a plan how to tackle the issue. There are a lot of complaints about problems for existing builders working on Cardano right now (however we can hear those complaints loud and clear)- but we can't hear the complaints of the people who tried on their own, gave up and left. There is a lot of inward focus on teams who are here right now. Yes, they are our stars and building up the ecosystem. Data presented shows our environment is rich with senior heavy devs. We are not attracting junior devs who don't even enter... or give up as soon as they see the fragmented onboarding experience. Ultimately, I don't care who was responsible - what we need is to eliminate this lack of competition - or lack of inflow if you want - and a limited number of ideas circulating in a small circle of partners or rivals. Furthermore, this proposal is also fertile ground for cooperation among relevant people at IOG, CF and Intersect and others. From the feedback that I have received publicly over X to my questions - I see there is willingness to cooperate. Cardano will fail if everyone has to climb a mountain or devote months to learn how to start or must have a special talent to start building here. Lowering the entry bar will ultimately lower the costs for the ecosystem - that is what I want to see. This will also increase the value and utility of each and every tool that we have collectively financed so far. This is a public goods proposal that I can support as my original concerns have been sufficiently well addressed. I would advise the proposers to keep the collaboration spirit alive - a proposal like this will fail without it.
- Abstain 6.2M ₳ No rationale
- No 6M ₳ Rationale
I am voting No.
Improving developer experience is directionally positive, but this proposal continues a pattern we’ve leaned on for years—investing in better tooling with the expectation that adoption will follow. That hasn’t consistently proven true.
At some point, we have to acknowledge that the primary constraint is not just developer friction, but the lack of sustained user demand and economic activity to build for. Without that pull, improvements here risk being incremental optimizations rather than meaningful drivers of growth.
I don’t question the value of this work, but I do question its priority relative to the gaps we still have in attracting users and real usage into the ecosystem.
- Yes 5.5M ₳ No rationale
- Yes 5.5M ₳ No rationale
- Yes 5.3M ₳ Rationale
Voting YES. The smallest ask in the IO 2026 batch and arguably the highest leverage. Cardano grows by zero net developers per year while Ethereum adds 1,940 and Solana adds 884 - the developer gap is the upstream cause of every downstream complaint about the Cardano ecosystem, and this proposal is the most direct, evidence-based response to it. Five practical outcomes coordinated as one program: a setup CLI that takes new builders from zero to working project in minutes, an OpenZeppelin-style ready-to-use contracts library, a unified Developer Portal entry point built in collaboration with Intersect and the Cardano Foundation, community-aligned bounties paid to maintainers of existing tooling, and a measurement hackathon that quantifies the result.
The proposal soundness is grounded in real research, not assertion. A 109-developer survey, GitHub activity datasets, and comparative growth rate analysis surface the actual barriers - immature and fragmented tooling, scattered documentation, steep EUTXO learning curve, lack of ecosystem coordination. The strategy then maps each barrier to a specific deliverable. Stewardship of developer relations transitions to the Cardano Foundation by end of 2026, which is precisely the distributed-ownership outcome the Cardano 2030 Vision is designed to produce. The bounty model deliberately funds existing community maintainers rather than building parallel infrastructure - that is the right structural instinct. Same gold-standard treasury safeguards as the rest of the batch. The downstream coupling matters too: the contracts library feeds directly into Cardano High Assurance for formal verification, and cardano-init is the integration surface for the High Assurance plugin architecture - the proposals across this batch are designed to compound rather than compete.
Peter Horsfall - Independent DRep, Oceania.
- Yes 5.3M ₳ Rationale
STORM Partners votes YES on the IO Developer Experience Initiative.
Cardano’s adoption challenge is not only technical capacity. It is also developer onboarding, usability, and the ability for new teams to build without excessive friction. This proposal is practical, relatively modest in size, and focused on reducing barriers for builders.
Our caveat is attribution. Developer growth will depend on more than this proposal alone. Still, improving the developer experience is necessary if Cardano wants more applications, users, and transaction volume. We support the proposal and expect success to be measured by real developer usage, not documentation output alone. - No 4.8M ₳ No rationale
- Yes 4.8M ₳ No rationale
- Yes 4.5M ₳ No rationale
- Yes 4.4M ₳ No rationale
- Yes 4.2M ₳ Rationale
[Portuguese]
Optamos por votar "SIM" nesta ação de governança "IO: Developer Experience Initiative" (gov_action1w0shrfxqwv95kk0v4cn34wylz25a2cmqkq5jpc0e2yrahhqava3qqfu3vtv), pois entendemos que ela enfrenta um dos gargalos mais relevantes para o crescimento sustentável da Cardano: a experiência dos desenvolvedores. A iniciativa apresenta entregáveis concretos — como melhorias no Developer Portal, criação do cardano-init, biblioteca de contratos, bounties para ferramentas do ecossistema e um hackathon de medição — que podem reduzir barreiras de entrada, acelerar o onboarding de novos builders e gerar impacto direto em adoção, utilidade e crescimento do ecossistema. Embora o valor solicitado, de ₳3.601.926, seja significativo, consideramos que o orçamento apresenta uma boa relação custo-benefício diante do escopo e do impacto esperado, especialmente por concentrar a maior parte dos recursos em desenvolvimento e engenharia. Também pesam positivamente os mecanismos de controle e transparência previstos, incluindo entregas por marcos, critérios de aceitação, acompanhamento pela Intersect, asseguração independente, prestação de contas pública e devolução de valores não utilizados ao Tesouro.
[English]
We chose to vote "YES" on this governance action "IO: Developer Experience Initiative" (gov_action1w0shrfxqwv95kk0v4cn34wylz25a2cmqkq5jpc0e2yrahhqava3qqfu3vtv), because we believe it addresses one of the most relevant bottlenecks for Cardano’s sustainable growth: the developer experience. The initiative presents concrete deliverables — such as improvements to the Developer Portal, creation of cardano-init, a smart contract library, ecosystem tool bounties, and a measurement-focused hackathon — which can reduce entry barriers, accelerate onboarding for new builders, and generate direct impact on adoption, utility, and ecosystem growth. Although the requested amount of ₳3,601,926 is significant, we consider the budget to present a strong cost-benefit ratio given the scope and expected impact, especially since most of the resources are concentrated on development and engineering efforts. We also view positively the proposed control and transparency mechanisms, including milestone-based deliverables, acceptance criteria, oversight by Intersect, independent assurance, public reporting, and the return of unused funds to the Treasury. - Yes 4.2M ₳ Rationale
Prioritizing core development and strategic marketing is key to Cardano’s long-term success—build strong technology, drive adoption, and the price will follow. Now is not the time to cut funding for key initiatives that helps user adoption and developer experience.
- No 4M ₳ No rationale
- No 3.8M ₳ Rationale
A valuable proposal which I am unable to support as all developer experience should not be under the IO umbrella, but needs to be under an independent organization. I would look differently on this if it was Cardano Foundation or Intersect.
A PDF version of this rationale is also made available.
The underlying problem this proposal addresses is real. Cardano’s developer experience is not currently competitive, onboarding friction is too high, and the ecosystem does need significantly more builders and experimentation. DevEx improvements are a legitimate public good and treasury appropriate in principle. Timing is also reasonable, as the ecosystem cannot afford continued stagnation in developer growth.
However, after evaluating this proposal through the lenses of strategic fit, treasury suitability, governance impact, ecosystem incentives, and execution structure, I cannot support it in its current form.
My primary concern is institutional and governance related, not technical. IO should not become the canonical owner and standard setter for developer experience across the ecosystem while simultaneously being treated as one technology vendor among many. This proposal further concentrates ecosystem coordination, tooling direction, documentation ownership, and developer onboarding gravity into IO. Long term, that creates unhealthy dependency and weakens ecosystem decentralization.
There is also significant overlap with work that is more naturally suited to organizations such as the Cardano Foundation or Intersect, both of which are structurally better positioned to steward ecosystem-wide standards, coordination, and developer enablement functions. I do not believe treasury governance should reinforce the pattern where IO requests funding for every strategically useful initiative simply because it has the capability to execute it.
I also remain unconvinced by the evidentiary basis used to justify the scale and expected impact of the proposal. The proposal correctly identifies developer friction, but the supporting data and causal assumptions are relatively weak compared to the confidence of the projected outcomes.
For these reasons, while I believe the ecosystem problem is real and worthy of investment, I am voting against this specific proposal structure and ownership model.
- Yes 3.7M ₳ Rationale
I support IOG’s initiative to consolidate and advance developer tooling and documentation. This is a well structured plan for something critically important to the ecosystem and I believe IOG can deliver far more than the projected 30% increase in growth rate.
==========================================
In general (and this applies to all IOG proposals), I firmly believe Charles is the most capable leader to guide Cardano into its next phase. With his experience, resources, technical knowledge, his army of developers, researchers and strong personal incentive for Cardano’s long term success, I will vote in favor of everything his company proposes. I wish we had even better alternatives, but we don't, cause there aren't any.
Since I am not a technical expert (particularly in this AI driven era), I will not pretend to fully evaluate the cost of these initiatives. That said, for a blockchain with a $10 billion market cap, an annual investment of approximately $40 million in core development does not seem excessive, especially in such a fast moving and highly competitive industry. Ultimately, this level of funding only makes sense if one trusts the incentives and capabilities of the person responsible for managing these resources.
I have also carefully reviewed the arguments circulating on X against funding IOG and find them unconvincing, as they never offer any viable alternative path forward. This includes the so called “conflict of interest” concerns regarding Midnight Ambassadors who are also DReps.
For transparency, I maintain close and regular communication with my 240 delegators through our Greek DAO Discord channel and update them via YouTube videos. They fully understand and expect me to ignore the social media noise, chaos, and paranoia, and instead follow common sense and what is genuinely best for Cardano. - Yes 3.5M ₳ No rationale
- Yes 3.1M ₳ No rationale
- Yes 2.9M ₳ No rationale
- No 2.8M ₳ Rationale
While I agree that there are clear issues with fragmented tooling, scattered documentation, lack of coordination, and a steep learning curve, I have to vote NO on this proposal in its current form.
This is a good start to solve a real problem, but it is a problem that IOG and the Cardano Foundation created themselves. This could have been addressed early on by unifying a singular location for all things Cardano developper related, and would not need additional funding to solve.
I think this is still worthwhile exploring, but probably not the most viable solution to attracting and retaining developers. I believe this issue primarily lies in improving Cardano’s overall tooling and codebase simplicity, and supporting other proposals like these are a much better use of community funds:
- Pebble & Ecosystem maintenance: TypeScript core of Cardano
- IO: Cardano High Assurance Technical Collaboration
- IO & VacuumLabs: Enhancing Plutus - Performance, Correctness, and Usability
I recommend that IOG does further work ensuring that the Cardano Foundation, Intersect, and Cardano developers will use the desired designated tooling portal, and ensure that any developer can submit documentation and tooling to this portal. Once this proof is available, I am more likely to part with the ADA required to make this happen.
I am also uncertain that the requested costs of 3.6 Million ADA are justifiable for what is being proposed. If IOG cannot complete this work for less than the amount requested, I think this workload should be tendered out to other companies, as this mostly amounts to organizational work and I cannot see how this would require top tier salaried programmers to make this happen.
Also, in no way should any founding entity, like IOG or its founder Charles Hoskinson publicly attack and pressure Cardano community members and DReps into voting Yes for their proposals. This dishonorable and disrespectful behavior is unbecoming of any leader who wishes to be taken seriously and in turn granted respect.
If this behavior continues in the future, I will be downvoting every proposal by such entities who behave this way as a consequence. Please keep in mind that actions have repercussions.
I also do not appreciate IOG frontrunning the entire Intersect budget process with the intent of claiming the entire NCL for 2026 and leaving nothing for community builders.
I expect this proposal to complete all deliverables as stated, and if this is not done, IOG will receive no further Yes votes from me in the future.
- Yes 2.7M ₳ No rationale
- Yes 2.7M ₳ No rationale
- Yes 2.7M ₳ No rationale
- Yes 2.6M ₳ No rationale
- Yes 2.5M ₳ No rationale
- Yes 2.5M ₳ Rationale
devs must be happy to stick around
- Abstain 2.5M ₳ Rationale
Developer Experienceの改善はCardanoにとって重要であり、「Cardanoで開発を始めるまでの迷路を減らし、新規開発者が短時間でDApp開発に入れるようにする提案」として、cardano-init、Developer Portalの整理、スマートコントラクト集、バウンティ等の方向性は有用だと考えます。一方で、現段階ではまずCardano自体の魅力を高め、開発者が「Cardanoで作りたい」と思う理由を増やすことが優先だと考えます。本提案の必要性は認めますが、成果は間接的で、KPI測定や継続性にも不確実性が残るため、今回はAbstainとします。
I recognize that improving Developer Experience is important for Cardano. This proposal aims to “reduce the maze before starting Cardano development and help new developers begin building DApps more quickly.” I see value in cardano-init, Developer Portal improvements, reusable smart contract libraries, and bounties.
However, at this stage, I believe the higher priority is to make Cardano itself more attractive and increase the reasons why developers would want to build on Cardano in the first place. While I acknowledge the need for this proposal, its impact on developer growth and MAU is indirect, and there is still uncertainty around KPI measurement and long-term continuity. Therefore, I choose to Abstain. - Abstain 2.5M ₳ Rationale
Will update vote again after talking with IO team - initiative may be more aligned than originally thought. This is a huge problem on Cardano and if this proposal is simply creating a pipeline, not new tooling, i am well aligned.
- No 2.4M ₳ No rationale
- Yes 2.4M ₳ No rationale