Why is it important?
There are core functionalities that most projects need, community owned open-source solutions can make them available to everyone
What does success look like?
A healthy mix of both private and public groups build on top off, and contribute to, a solid and open foundation for development
Key Metrics to measure
Success of this proposal should be measured through the adoption of open source solutions by other projects:
- Usage of open source git repositories
- Usage of open source docker containers
At the end of this challenge it should also be easier for developers to find existing tools that help their project.
Have we managed to create public visible overviews of exisitng open source and free tools?
Other metrics could involve participating number of devs on open source projects, though this can be hard to track. We can track if events have been organised and seen participation to support open source projects
Challenge brief
This challenges aims too support the development of common tools needed for projects to make use of the cardano blockchain.
Briefing
There are core functionalities that almost all Dapp projects need like querying the blockchain, managing wallets, creating transactions. These functionalities should be freely available to all and be owned by the community. Some of these solutions are currently only easily available as Software as a Service solution. If most Dapps are build on top of the same proprietary solutions to access the blockchain, however, this leads to centralization and introduces risk.
The goal of Cardano is to also include those who are currently being left out. If the best tools build with the community fund are behind a pay wall this creates an unfair playing field. Anyone who wants to start building on top of cardano should be able to easily configure a node with the utilities they need. Anyone who is hosting a node (as SPO or otherwise) should be able to easily add on and offer additional services as they see fit.
Large scale projects and singular solutions have proven to be inflexible and the industry is focusing on compositional design. Modern micro service architecture and solutions like containerization allow for common utilities to be developed as self-hosted independent building blocks. This approach allows projects to focus on a single functionality reducing the risk for the whole community.
Guiding questions:
- How can we ensure future developers benefit from the work that is funded today?
- How do we promote a decentralised and self-hosted ecosystem?
- How do we align between different open source community efforts?
possible directions:
- developing common tools as libraries or containerized services
- incentive system for developing & hosting common open source utility's
- common audited repositories & overviews for open source solutions
- organising events to bring the open source community together
- collaborations/efforts on defining common standards
The Budget is set to be an additional 10% of the current proposed dev ecosystem challenge.
Challenge Team:
Due to time constraints and the short notice a team has not been officially formed. There has been contact with several other community members who have shown an interest. If the Challenge gets accepted a team will be formed and rewards would be shared fairly. The current member has experience with facilitating sessions, writing proposals and has experience working on open source projects as a developer & a product owner.
The Challenge team will try to work with existing open source intitiatives too provide proposers a way for proposers to build part of their roadmap. This is ofcourse voluntarry and proposers are free to do their own project within the scope of the challenge.
