Spoiler alert: 100x gains for time-to-dApp are unlikely for Plutus within Fund-10. By using this tongue-in-cheek, over-the-top title, Kriss Baird from IOG probably wants to highlight how difficult it currently is to build on top of Cardano, and that certain areas of dApp maturity are indeed only around 1% of Ethereum's and could do with a 100x boost. Case in point is DeFi, where despite a crash in Ether's value and the catching-up nature of Cardano after the Alonzo hardfork, only 0.5% of Ethereum DeFi TVL are currently on Cardano (at the time of assessment). Bridging this gap is super important for our ecosystem, as it currently stands in the way of real world users, which means active wallets, transaction fees, ADA value and Cardano reputation. With probably the best designed Proof of Stake pool operator network and unique features like domain specific languages and ISPOs, this challenge should be on the very top of the next several funds. Two of the four main strategic goals of Fund-10, 1. attract more open source developers, and 2. build real-world solutions are served extremely well by this challenge definition.

Plutus is the newly developed language for writing smart contracts on Cardano, and creating DApps and other products by utilizing this language is difficult. However, with the inception of the Plutus pioneer program and other supporting tools & resources such as Cardano stack exchange, and Gimbalabs, this has been overcome to a certain extent. Therefore, this challenge will help in further smoothening the development process by incentivizing the creation of developer supports tools and resources.

This challenge helps with the strategic goals as it prepares & trains the group of people who will be able and willing to contribute to the Cardano ecosystem. It also accelerates the growth of the developer ecosystem and thus enhances the creation of DApps and other products. The tools and resources created under this challenge must be open source to make them available for other projects to use & build their applications.

In terms of attracting votes, in Fund 8, the proposals under similar a challenge accumulate the highest number of votes combined. We can expect more or less the same again for this challenge. This challenge will be a springboard for Cardano adoption as it lays the groundwork for the future creation of DApps and other products on Cardano, which people will use worldwide. Given all the above points, this challenge is critical for Cardano's mission.

The challenge "Plutus 100x gains for time-to-dApp" is seeking to make the developer experience of building dApp using Plutus 100x more seamless to set up, inclusive and scalable. The challenge objective aligns with the strategic goal of Cardano by helping to create the environment where developer adopts Plutus smart contract functionality. The challenge will be a success if dev team and dapp companies build open source develop tools, understandable documentation and adapt according to the user need. The project that would fit into this challenge setting would be any platforms, products or mechanism that significantly reduce the time to dApp. The proposal also accommodate developers to enter Cardano (if their background is not haskell). The developer tools proposed under this challenge would have to be open source. It seems that the challenge have many different directions (reduce time to Dapp, attract outside developer and open source) although the title of this challenge only says to reduce time to dApp. It is great for the challenge to be broad but not too broad in my perspective as it will be difficult for proposals submission and assessment.

IOG has presented several of these challenge settings designed to secure funding allotments for developers building tools to help developers, but of all of them, I think this is the one that will be most popular with the developers (though Scala is a darkhorse: https://cardano.ideascale.com/c/idea/423239). End to end help with Plutus development is one of the biggest development roadblocks in the ecosystem, with Plutus engineering not scaling with community growth as much as we would like. Several challenges and many proposals come at this from different ways, such as encouraging Plutus adoption, building tools that let devs work around plutus with familiar tools they have experience with, and integrations like Plutarch that strip some overall flexibility and complexity for simplicity and ease of use.

This challenge is gathering all those ideas in one place with dedicated support and guidance. It doesn't limit the menu, either: I count 22 types of proposals they envision under this umbrella, so that suggest pretty wide accessibility and application. It is focused on opensource and interoperable, and it is focused on turning Plutus into a strength and feature that devs are happy to work with, so I would say that there is terrific alignment with the Fund 10 goals for this challenge setting. 5 stars.

It is true that to fully utilize the potential of Cardano, we need a vibrant and healthy developer ecosystem, when it comes to the number of devs as well as their experience. That's why there have been programmes like the Plutus pioneer programme and the Marlowe one that bring devs closer to the Cardano ecosystem, adopting languages and architecture build on the Cardano blockchain rather than any other blockchain. That's why an increase in documentation and an enhacement on the whole open-source concept would have a societal impaact on the ecosystem. As developers are the core of every blockchain, i believe that this challenge could be critical to achieve Cardano's mission.

Alignment with the strategic goals is paramount for any challenge setting, and this proposal is right on target. Building tools to further Plutus development and ease of integration will enable Cardano to scale more rapidly and create the core community of developers necessary to achieve this. Proper resources are necessary for the community to steer the ship, powered by Catalyst, in the direction of mass adoption and facilitated innovation. This IOG initiated challenge fires on all cylinders.

I strongly agree that this challenge is critical to achieve Cardano’s mission. As Cardano is preparing for the Vasil hard fork in the upcoming weeks of 2022, we will see significant improvements such as pipelining, reference script that would allow many dApp project teams to finally launch their projects on mainnet.

Nevertheless, As a Senior developer myself one of the biggest obstacles Cardano is facing is time to onboard and quickness to set up and run a prototype as quick as possible, for instance as this challenge mentions in perhaps a 2 day hackathon developers should be able to run a prototype, and rather not spend significant type in setting up the environments and tools, especially if they don't have any prior haskell or plutus experience..

A seamless and easy developer onboarding is critical if we want to build real world solutions on Cardano. IOG has come up with this challenge as I am sure they have taken community developers' feedback and experience with initial setup and tooling necessities to improve code and problem-solving reusability, therefore, helping Cardano’s mission immensely.

The goal of this challenge is to allow the submission of proposals that would make it easier to develop on Plutus, especially for developers that don’t have Haskell as a native language and are not used to programming in blockchain yet. The idea is to make it as simple as possible to integrate solutions and software with Cardano, and at the same time, increase scalability and accessibility. Some of the potential directions mentioned are, for example, identify areas that lack tooling, make it easier to set up dev environments and facilitate debugging of Plutus code. This challenge covers very well many of the aspects that would indeed make it easier to start using Plutus, and this is a real struggle in the community since Plutus is known to have a steep learning curve, and even people who have been through the Plutus Pioneers course sometimes struggle with simple things, so there’s a real need for this challenge. It directly addresses the goals of Cardano’s mission for Fund 10 of preparing a group of people - by facilitating their onboarding - a groups of people to contribute to the ecosystem, attract more developers and indirectly to turn Cardano into an open-source project and build real-world solutions. Overall, the alignment of this challenge setting with Cardano’s mission is very high.

Improving the developer ecosystem has been a priority for Cardano for many months, since Fund2 dedicated improvement challenges have always been present and this reflects the voting power these challenges received during the voting stages throughout Catalyst.

With the delivery of Goguen in 2021 and the updates being delivered, the Cardano blockchain acquires better performance and this increases the capacity/programmability that applications have to develop on top of Plutus.

This challenge aims to dedicate more funding for tool improvements, documentation, optimizations and improvements that can lower the entry barrier for Plutus programming and development of general open source solutions in order to avoid redundancy of work between projects developing solutions in Cardano.

This challenge is in line with items 1 and 2 of the Catalyst Fund9 Challenge Setting Strategic Goals mentioned in the Proposal Assessor Guide.

In a sidenote, iI would recommend avoiding definitions like "100x gains", "100x more seamless to set up", "100x more awesome", "…reduce the time it takes to go from zero to hero while building and deploying dApps…" see these catchphrases in a challenge proposed by IOG is unacceptable, mainly because they were used as catchphrases with no metrics attached.

Templates and "all kinds of tooling" sound slightly dangerous to me when it comes to 100x scalability and implementation improvements :-) But I agree with the other metrics, they are excellent. Greatly lowering entry barriers for new devs, improving scalability for existing implementations and programs to incentivize testing and proofs would be highly suited to measure progress. I would probably drop multi-language support for this particular challenge, as there are already a lot of translation proposals at the moment. I would have liked to see mention of other programming languages alongside multi-language support. For immediate gains leading to 100x, we need more compatibility with programming languages. For example, JS-like deployment tools that devs can use easily, more Python-like packages and implementations, and more C-like links to plugins and engines for app or game development, to name a few.

The author mentioned many metrics in the challenge, which will be helpful not only to measure the challenge's success and proposals' success but also to track/audit the progress of proposals under development.

In addition, the author wonderfully laid out the potential directions and guiding questions. These details will assist the community in finding which tools and resources are lacking and will motivate the developers to propose solutions for them. Furthermore, it will also help the PAs to assess the proposals, and the voters to vote decisively.

The key metrics this challenge setting proposals provide are developer activity on GitHub repo, and also activity on the sample dApp templates, # contributors to open source developer tools and # users of developer tooling Github repo. Although the proposal could add measure number of developers outside the chain that has started developing on Cardano as a result of these developer tools and their feedback on how they find setting up the environment.

The KPIs for this challenge setting lean very heavily on its open source nature, and consist primarily of github repo metrics, from activity levels to # of participants, etc. I went back to the proposals for things like Plutus-Scala integrations, or Plutarch maintenance and looked to see what kinds of KPIs were provided. I then cross-referenced this to the list of developer ecosystem completed proposals, Plutus based or not (see a nice community built list here: https://dynamicstrategies.io/docs/catalyst-delivered-projects/) and checked their completion reports. I didn't see a single non-repo based metric used for measuring progress or success across either of these criteria (even hackathons were validating success with forked repos). I guess what I am saying is that despite really only having one flavor of metric, sometimes that is all you really need.

They also include a list of more general success criteria, but what really stands out from this is the idea of parsing how much quicker teams are able to bring dapps through from concept to completion. They say 100x in the title, which is a little hyperbolic, but that kind of paradigm change is what they are targeting, and the inclusion of the KPIs for setting up developer environments, testing and debugging environments, and formal verification tools is providing the data that informs this kind of success criteria.

Because the effectively listed relevant KPIs and achievable, high level metrics for progress and success, I believe this proposal warrants 5 stars.

We have well-defined success criteria and success metrics that are long-lasting in multiple funds that need minimal adjustments to meet the strategic goals. They are precise yet give enough room for a wide variety of proposals. I like the fact that they are pretty detailed for example when referring to the percent of activity on Github repos, they also refer to the induvidual items that the activity refers to such as the views, the feature requests, the issues etc.

This challenge setting relies largely on Github to assess the metrics of clearly defined KPIs. Transparency and detailed analysis are hallmarks of verification, and this proposal identifies the growth of developers, both in numbers and in contribution to new tool creation, as some of the Key Progress Indicators needed to audit the progress of this proposed challenge. Other measures of success include community discussion and involvement, monitoring of new dApp development, and the number of open source tool creators. Literally anyone can visit Github or view open source code, thus the ability to audit the efficacy of this challenge will be completely transparent.

The challenge mentions that success would mean that Dev teams and dApp companies basically provide generalized open sourced developer tools and easy to interpret documentation, with a quick feedback loop. The key metrics to measure details out plan in terms of Github activities, such as # of views, feature requests, comments/questions, downloads, dApp templates, contributors numbers etc.

Additionally, additional success criteria, along with guiding questions and inspirational potential directions are well detailed out, helping proposers to have certain ideas being proposed in this challenge rather than in other challenges such as the Developer ecosystem or dApps category.

It would have been also great if numbers such as 100x gains were avoided in the title and brief, as there is literally no way to measure this accurately. I understand that this is an expression of a multiple folds increase in developer experience, but for a technical challenge like this, it would be better to stick to some better terminology. Finally, I agree that success criteria and suggested metrics are set correctly to measure progress in addressing the challenge.

The KPIs suggested by the proposer to measure the success of this challenge are good. They are mainly related to GitHub activity and number of views, features requests, issues, discussion, download, number of repos, contributors to open-source tools. These KPIs will provide a good overview of what’s being developed through the utilization of the funds of this challenge. I would like to see some KPIs related to different areas of development, for example, how many projects have been funded to work on multilanguage support, how many open-source tools, how many platforms and products have been developed, projects related to reading/writing on the blockchain and others. But overall, I believe the KPIs provided are good, and adding the suggestions I’ve made here would increase the number of insights that the community could have about this challenge and understand what areas need more attention. Overall, I believe the verifiability of this challenge proposal is good.

The definition of success for this challenge is well designed and allows the outcome of the challenge to be evaluated from different points of view. When reading the additional success definitions, we can see items that allow us to assess the ease and speed in Plutus onboarding of new developers, variety of solutions (tools, SDKs, documentation, libraries, APIs, plug-ins, etc), number of open source solutions , demos and application templates.

The proposed key metrics suggested are reasonable and suggest measuring the activity related to the development of tools and template applications in repositories, something appropriate to the context of the challenge. Key metrics also suggest using the number of contributors as a reference. I would recommend including items that allow you to assess the outcome of the challenge over time to make the verification more accurate.