This challenge is more than critical to achieving Cardano's mission. We can think about how critical this is, but to restate one of the goals is to turn Cardano into an open-source project. With the current challenge settings, we attempt to include this goal by indirectly introducing it to challenges. However, this challenge is an attempt to directly address visibility and open collaboration among developers, both of which are fundamental for a growing ecosystem. At our current stage, many of the projects are being kept internalized and the baseplate of a project is always kept at 0. Either the same company or a licensed collaborator can build upon that base or it will never get its attention again. By using this challenge setting, we are setting up a huge market for reusability and keeping the ecosystem relatively healthy by saving resources from companies that could invest that potential into somewhere that may still be undeveloped.

This proposal is a continuation of the long standing opensource challenge setting in Catalyst and is characterized by the strong challenge team that is supporting it along with its obvious hardcore alignment to get developers creating and contributing to opensource.

As such, this iteration has really highlighted the building of community and collaborative approaches, which isn't always part of an OSS projects roadmap, despite the idea that collaboration is what unlocks the value of making something opensource in the first place (collaboration being on a somewhat higher plane than just "sharing"). Other challenge setting proposals with similar goals and budgets in this fund include the veteran Developer Ecosystem team (https://cardano.ideascale.com/c/idea/422540) which doesn't require opensource but has a strong pivot there this fund ($2m), and the broad Funding Category experiment Development and Infrastructure (https://cardano.ideascale.com/c/idea/414308) which also is not exclusively opensource ($2m).

This challenge setting has performed well in the past, pulling in 25,803 unique votes in Fund8 and averaging 300(!) votes per project. For perspective, only the above linked Developer Ecosystem performed better with 26,030 unique votes and 531(!!) votes per project. If there is a key difference between the performance of the two, it is that DevEco tends to fund larger projects, while opensource tends to support small and medium size projects. Either way, it is a high impact area of the ecosystem.

Because the team has made very clear their deep opensource alignment (Fund10 goal#2) and also prioritized community building in opensource (Fund10 goals #1 and #4), I believe it has achieved an exceptionally strong alignment score. 5 Stars.

I strongly agree that this challenge is critical to achieve Cardano's mission. The open source dev ecosystem is fulfilling all four Fund 9 strategic goals. As an example, the first goal states - preparing a group of people willing to make contributions to the ecosystem. - something like the Gitcoin equivalent open source quadratic voting proposal funded in fund 8.

Secondly, recently Cardano has become a prestigious member of Linux foundation and therefore the word is out there that Cardano must and fulfill its legacy of turning into the largest decentralized and yet open sourced blockchain.

The key metrics presented such as increase in the number and quality of open source projects, contributors, tools and frameworks perfectly align with the challenge settings.

This challenge proposal has the goal of allowing submission of proposals related to developing tools and projects that are open-source and therefore available for all the Cardano community to use. This challenge has already been funded a few times before and it has been very successful in both number of proposals submitted and what they have accomplished. It allows for creation of, for example, open-source tools, frameworks, core infrastructure, PoC’s and much more. Also, they mention explicitly that there’s space for proposals that want to increase the visibility of open-source tools built on Cardano, which is something that is many times missing in the ecosystem, since many projects and tools are built but are never used. Besides supporting the development of the whole Cardano community, this challenge setting is directly and very well aligned with Cardano’s mission for Fund 10 to make it an open-source project and attract more developers. At the same time, it indirectly contributes to the creating of real-world applications on top of Cardano. The alignment of this challenge proposal, therefore, is very high.

Building a robust developer ecosystem has been a priority when thinking about Catalyst/Cardano since Fund2. Cardano has undergone many technical upgrades in 2021 and 2022. Goguen, Alonzo and Vasil are delivering tools and possibilities that greatly expand the type of applications that can be developed, but for these applications to be developed it is necessary that developers have access to tools , documentation, courses, SDKs, among other solutions. Many of these implementations and developments end up becoming open source and this makes Cardano's blockchain more complete and accessible, but open source development in many cases ends up not having enough financial incentives to stimulate the necessary dedication and in this context Catalyst and funding by Cardano's treasury is essential to leverage this development.

The challenge also understands the importance that commercial projects have part of the non-open source code for commercial interests, but the focus is on open source development, however there is a problem in the description of this challenge, from which I will not deduct points because the problem is the most related to clarity in description than the Catalyst evaluation criteria.

In some parts it implies that only open source proposals can participate ("…and it is not to be confused with other challenges that don't require open-sourcing a project to the community.") the word "require" implies that the challenge will restrict proposals that are not intended to be open source, but in other parts of the description the idea is that it is important to maintain commercial value and that only part of the code being open source is acceptable ("The projects funded by Catalyst should be able to generate business value retained by the teams, and at the same time contribute back to the Cardano community." ).

I understand this conflict, it is natural for projects to want to maintain some strategic business advantage, but this leaves room for projects that open source all their code and projects that open source only 1% of their code. The challenge concept is promising but it is important to clarify the criteria for what is considered "open source" and acceptable within this challenge. Without a clear definition any commercial project can submit a proposal, create any code or documentation and make it public just to call itself open source. The intention of the challenge is excellent, but without clearer criteria, the purpose ends up being compromised. As I mentioned before I will not deduct points as 10% or 100% open source, the challenge remains aligned with the Catalyst Fund9 Challenge Setting Strategic Goals and continues to be important, as the developer ecosystem is extremely important in the Cardano mission.

Due to the similarity in the themes of some challenge settings, parts of my assessments will also be similar.

With the recent vocal initiatives from IOHK/IOG and the Cardano Foundation to nudge the Cardano global ecosystem towards an open-source model of development (some 10 days ago the Cardano Foundation announced its membership with The Linux Foundation, the nonprofit organization enabling mass innovation through open source). This challenge comes at an opportune time to strengthen this commitment and to build upon the achievements of the previous Fund 8 Open Source Development Challenge. I would comment the proposing team for posing a very good challenge question. We indeed need to we build [and I would add “sustain”] a community-owned Open-Source Ecosystem that’s commercially viable to drive growth… for the whole Cardano Community. We all know that Cardano’s open-source ethos from the very beginning has been one of its key driving forces behind wide adoption and this challenge is clearly excellently aligned with Cardano’s mission.

Even though we already have constant challenge category “Developer Ecosystem” which is highly likely will be in the next Fund, I’m sure there is both room and the budget for additional category. Bear market is time for development. Charles Hoskinson always speaks in favor of open source software. Moreove in cryptocurrency industry if the software is not open source it’s suspicious and even I would say - not common. So I believe to have Open Source development and Open Source category in Catalyst is very important.

The verifiability of this proposed challenge sufficiently manages and measures the progress of any proposals within the challenge. It is easy to key in and find the growth of the challenge by measuring the number of users and developers that are keen to push for proposals in the challenge. This success criteria accurately depicts how popular and innovative an idea is. As we have grown in the user base, we also improve upon the infrastructure and the quality of the projects. The success criteria effectively describe a properly functioning challenge. In terms of key metrics to measure progress, we have the number of projects, tools, contributions (developers), and documentation. Some of the criteria can be grouped together, but the explicit nature of listing the metrics helps avoid any discrepancies. These metrics help us understand how well the projects are working to help collaborate and give value to other projects. The simple goal does not remain to be just building and finalizing the project, but rather to build the project that can easily be expanded upon and help integrations among other projects. Therefore, these metrics are qualifying and sufficient to measure progress and growth in addressing the challenge.

There is an excellent list of KPIs and metrics that proposers can use to target the Fund10 goals, but one in particular deserves attention. They have a general KPI that immediately arouses my cynicism, as it states "increase quality of opensource projects"… These type of abstract KPIs are always red flags for me that a proposer may not have a good grasp of their goals.

However, as I read through the proposal, they end up providing numerous examples that pin this abstraction down (many related to documentation, the low hanging fruit for all projects or processes to improve their quality): commit resources to documentation, include corporate viability elements like professional risk analysis and integrity controls, adopt and build frameworks rather than one-off solutions that result in duplication of work, and more. These are clear, actionable, measurable and deliverable, and this is the kind of guidance that serves proposer's well under a challenge setting.

Because the team has provided thoughtful metrics in line both with the Fund10 goals but also with the widest benefits of Opensource adoption, I believe this proposal merits a full 5 star rating for Verifiability.

I strongly agree that the success criteria and suggested metrics are set correctly to measure progress in addressing the challenge. Compared to the previous round challenge description, the write-up for the Fund 10 open source challenge is much improved. As a Senior developer myself, I can see that the challenge team has clarified and written the success and key metrics in a concise manner, leaving little room for doubt on what kind of proposals should fall under this category, should this challenge be voted by the community.

Additionally the success metrics are clear as the quality and number of open source projects being launched on Cardano grows while talented and expert engineers/developers not only contribute but also maintain these projects in the long run. The examples given further sets the tone for future ideas that will fall under this category.

The KPIs provided by the proposing team are appropriate and they can be used to measure the success of the challenge. They measure the number and quality of open-source projects, tools and frameworks, contributors and maintainers, tools visibility, collaboration, documentation, and integration/interoperability. I believe there is nothing missing in this challenge to properly verify its success. Maybe adding some metrics about how many projects were successful and how many have failed, but this is a general KPI that is not specific for this challenge, and that I believe will be verified in all challenges in the future. Overall, I believe the verifiability of this challenge proposal is very high.

The definition of success for this challenge is clear, objective and consistent with the premise established in the challenge setting, which I believe is appropriate as a definition of outcome. Several key metrics were included that will be appropriate to capture the quantity and quality of open source contributions (tools, documentation and SDKs), # of contributors, level of collaboration between peers and interoperability, among others. All this information can allow a good outcome assessment in this challenge.

There is no time window for defining the success of the challenge and the key metrics do not establish a timeframe to serve as a comparison, I would recommend including timeframes to facilitate checking the outcome of the challenge over time.

The team behind this challenge setting submission has proposed a very simple but effective definition of success. Not only quantity, but also the quality of projects is seen as the definition of success, as well as building much-needed open-source infrastructure – which is expensive if done correctly and securely and efficiently. The listed eight metrics are good and relevant. Some might be overly general and might be better formulated such as “Improve adoption of Cardano technology”. If the proposal for a open source dev ecosystem is not funded this time around, I would also advise the team to add a metric and components that would foster the development of critical open source research for developers as many of the new ecosystem advances are also dependent on the results of research that is not protected, patented or siloed away.

The team is great and experienced. The budget is not small, but reasonable. Key metrics is well-defined. I especially agree and want to underline that this proposal will help to Improve adoption of Cardano technology and will Improve integrations and interoperability between projects. The future is open source!