Open Source Developer Grants Program
We propose the establishment of an Open Source Developer Grants Program to support individuals and small teams in developing open-source software for the Polkadot ecosystem. This initiative aims to fund up to 15 projects with grants of up to $30,000 each, focusing on those with a proven background in open-source software development. Projects can include proofs of concept, general-purpose libraries, or full-scale dApps that benefit the Polkadot ecosystem.
The primary goal of this bounty is to streamline the grant process for applicants, providing an alternative to the W3F Grants Program and traditional treasury funding. By consolidating the discussion, evaluation, and processing of technical proposals into the hands of curators, we aim to create a more accountable and effective decision-making process. Unlike the W3F Grants Program, which is managed solely by the foundation, this bounty will feature multiple community curators, offering varied perspectives on funding open-source development. The milestone-based payment system ensures continuous feedback, allowing curators and teams to adapt their work to meet community expectations.
Proposed Curator Set
- Diogo Mendonca from Ditavia
- Tommi Enenkel from Alice und Bob
- Otar Shakarishvili from JUST Open Source
- Luca von Wyttenbach from Polimec
- Sebastian Müller from Web3 Foundation
For more details on the proposal and to participate in the discussion, please refer to the full proposal here.
Comments (3)
Child Bounties
Comments (3)
This would be for any open source developers so could help rustc developers? Would love to see Polkadot somehow be a member of the rust foundation.
This bounty is asking for the almost the same amount of DOT tokens as the AMI Bounty Program https://polkadot.polkassembly.io/referenda/562.
It appears to be strategically requesting funding as 5% commission, to be paid and distributed equally to curators for relevant work only after evaluation of project deliverables. This is half the commission that the AMI Bounty Program requested.
They also appear to be absorbing establishment and ongoing "administrative work" costs into that 5% commission to avoid their bounty being subjected to the same fate of being closed by the community the same way as the AMI Bounty Program was here in Polkadot Referenda #1033, which impacted that team as described here, because it paid its curators for necessary establishment costs in the early stages of evaluating bounty applications, even though those payments were approved by OpenGov, but because it was labelled as a "sign-on bonus" rather than just a "post-establishment administrative milestone payment", the community shut them down.
Please kindly update the proposal with the following:
— A requirement for curators to publish detailed timesheets for the community to scrutinise for OpenGov due diligence purposes, similar to what the AMI Bounty Program was required to do, so that community members are able to scrutinize the timesheets like this.
— Real-time adequate ongoing support, similar to that provided by the ink!ubator, but providing where the curators in this bounty provide an improvement on the response time of that bounty https://polkadot.subsquare.io/referenda/1160
— Update the application process providing a commitment to end with constructive feedback being provided to all applicants within a reasonable timeframe of say 30 calendar days, and include how well that turn-around was achieved as a metric in a one-off post-application evaluation report that covers all applicants, on whether they were successful or not, and that includes the results of a comprehensive application evaluation process satisfaction survey that the OpenGov community may contribute to and that all applications are requested to submit within 10 calendar days after the curator feedback timeframe mentioned above, so they may improve themselves for future applications to this grant or any other grant across this or another ecosystem. It shoud not be just a statement that the curators will "try" their best but never actually bother to provide any feedback. It is inadequate for the application process to just end with "judgement by the curators".
For example, based on my own experience the W3F turned around feedback the day after I applied for the Decentralized Futures Program, however I still haven't received any feedback from JUST Open Source after an unsuccessful research grant application over a month ago, which has made it difficult for my team to bring closure to their experience and to consider applying again to it or any other grant applications like this one, since they don't know what they did wrong even though we provided an exhaustive list of what we thought we may have done wrong to make their feedback process easier, and even though the reviewers may have said they were impressed by our application and encouraged us to apply to future offerings.
— Create a different proposal for "appointment of curators" or justify why that would not be necessary, and update that proposal to explain the curator replacement and onboarding and offboarding process that would occur in the case of a replacement of one or more curators or due to a conflict of interest or similar arising and how the OpenGov community could participate in the selection of an appropriate replacement of one or more members rather than an inappropriate replacement curator being selected solely by the current curator set.
For example, if multiple curators all face a conflict of interest, please show how you would onboard appropriate additional external curators and offboard the existing ones.
Please also explain whether those costs are included or would require a variation, noting that the AMI Bounty Program team had to absorb the administrative costs associated with offboarding curators and projects when they were closed.
The benefit of having a different proposal for "appointment of curators" from this one may be that it could be possible for the community to close that proposal and replace it with a new proposal that has a new set of curators at the same time incase the community requested most of the all the current curators to be removed and they expected a higher commission, without substantially affecting this proposal that funds each grant, where there may be a requirement to fulfill milestone payments and where administrative offboarding disruption costs may be more costly.
Please kindly explain why you believe only five (5) curators are adequate given that your meagre administrative costs, and what effort you have made, if any, to accommodate more members within the same or similar meagre budget. For example, the AMI Bounty Program had twelve (12) members for a similar budget, and the pipeline of evaluating proposals was often impacted based on the availability of each member.
This would be for any open source developers so could help rustc developers? Would love to see Polkadot somehow be a member of the rust foundation.
This bounty is asking for the almost the same amount of DOT tokens as the AMI Bounty Program https://polkadot.polkassembly.io/referenda/562.
It appears to be strategically requesting funding as 5% commission, to be paid and distributed equally to curators for relevant work only after evaluation of project deliverables. This is half the commission that the AMI Bounty Program requested.
They also appear to be absorbing establishment and ongoing "administrative work" costs into that 5% commission to avoid their bounty being subjected to the same fate of being closed by the community the same way as the AMI Bounty Program was here in Polkadot Referenda #1033, which impacted that team as described here, because it paid its curators for necessary establishment costs in the early stages of evaluating bounty applications, even though those payments were approved by OpenGov, but because it was labelled as a "sign-on bonus" rather than just a "post-establishment administrative milestone payment", the community shut them down.
Please kindly update the proposal with the following:
— A requirement for curators to publish detailed timesheets for the community to scrutinise for OpenGov due diligence purposes, similar to what the AMI Bounty Program was required to do, so that community members are able to scrutinize the timesheets like this.
— Real-time adequate ongoing support, similar to that provided by the ink!ubator, but providing where the curators in this bounty provide an improvement on the response time of that bounty https://polkadot.subsquare.io/referenda/1160
— Update the application process providing a commitment to end with constructive feedback being provided to all applicants within a reasonable timeframe of say 30 calendar days, and include how well that turn-around was achieved as a metric in a one-off post-application evaluation report that covers all applicants, on whether they were successful or not, and that includes the results of a comprehensive application evaluation process satisfaction survey that the OpenGov community may contribute to and that all applications are requested to submit within 10 calendar days after the curator feedback timeframe mentioned above, so they may improve themselves for future applications to this grant or any other grant across this or another ecosystem. It shoud not be just a statement that the curators will "try" their best but never actually bother to provide any feedback. It is inadequate for the application process to just end with "judgement by the curators".
For example, based on my own experience the W3F turned around feedback the day after I applied for the Decentralized Futures Program, however I still haven't received any feedback from JUST Open Source after an unsuccessful research grant application over a month ago, which has made it difficult for my team to bring closure to their experience and to consider applying again to it or any other grant applications like this one, since they don't know what they did wrong even though we provided an exhaustive list of what we thought we may have done wrong to make their feedback process easier, and even though the reviewers may have said they were impressed by our application and encouraged us to apply to future offerings.
— Create a different proposal for "appointment of curators" or justify why that would not be necessary, and update that proposal to explain the curator replacement and onboarding and offboarding process that would occur in the case of a replacement of one or more curators or due to a conflict of interest or similar arising and how the OpenGov community could participate in the selection of an appropriate replacement of one or more members rather than an inappropriate replacement curator being selected solely by the current curator set.
For example, if multiple curators all face a conflict of interest, please show how you would onboard appropriate additional external curators and offboard the existing ones.
Please also explain whether those costs are included or would require a variation, noting that the AMI Bounty Program team had to absorb the administrative costs associated with offboarding curators and projects when they were closed.
The benefit of having a different proposal for "appointment of curators" from this one may be that it could be possible for the community to close that proposal and replace it with a new proposal that has a new set of curators at the same time incase the community requested most of the all the current curators to be removed and they expected a higher commission, without substantially affecting this proposal that funds each grant, where there may be a requirement to fulfill milestone payments and where administrative offboarding disruption costs may be more costly.
Please kindly explain why you believe only five (5) curators are adequate given that your meagre administrative costs, and what effort you have made, if any, to accommodate more members within the same or similar meagre budget. For example, the AMI Bounty Program had twelve (12) members for a similar budget, and the pipeline of evaluating proposals was often impacted based on the availability of each member.