# Context The Radicle Funding team is creating a v2 of the Drips app, with the goal of helping Open Source projects and developers get funded for their contributions. As the team's developing new product features to support this mission, there are a few areas of user research that will inform product design. # Goals The goals for the following research includes: ### Understand both sides of the funding marketplace We'd like to better understand the two main players in the funding ecosystem: **projects** and **funders**. For **projects** that are looking for funding, the topics we'd like to understand in more detail are: - What are they looking for in terms of sponsorship partners? - How do they decide which benefits they offer to potential sponsors? - Are they currently share funding with their projects' dependencies? - If so, how do they currently implement this? - Are there any benefits that they would like to offer funders that are currently not available to them? For **funders** that are considering funding a project, the topics we'd like to understand in more detail are: - Why do they want to provide funding for open source projects? - What criteria do they use to choose which open source projects they fund? - What benefits are they interested in when sponsoring an Open Source project? Why? ### Understand operations for crypto-specific Open Source projects Since the Funding product relies on blockchain and cryptocurrency technology by nature, it's likely that crypto-based projects will be the most open to utilizing our product. We'd like to better understand: - What type of funders do they typically attract? - How are they receiving funding today for their projects? - Do they currently receive funding for their projects? - What is their stance on using cryptocurrency as a means of receiving funding? ### Understand implementations for dependency funding These set of topics deal more directly with a specific feature implementation that we'll be working on: **dependency funding**. The goal with this feature is to allow users to efficiently identify and stream funds to projects that they rely on. The topics that we'd like to cover are: - Are projects currently streaming any funds to their dependencies? - If not, is this something that they're interested in doing? Why or why not? - How would they currently identify projects that they depend on? - Specifically, how would they deal with various package dependency methods (Cargo.toml vs package.json, etc) - How would they want to set up their funding methods? Recipients and funding amount / duration? # Hypotheses These are a few key hypotheses that the team currently holds. Our goal is to either validate these hypotheses, which in turn will validate our product designs or allow us to adjust. 1. Companies have various motivations for funding a project, primarily dependent on company size. - Larger companies are looking for hiring prospects while mid-size companies are looking to influence the project. 2. Projects typically offer access and influence as the primary benefits given that's the current industry standard. 3. The current solutions to fund dependencies require significant manual set up, introducing a level of friction that prevents many projects from participating. # Strategy For the goals Our strategy to get the insights we're looking for are: ### 1. Identify a list of open source projects The first step would be to identify a list of open source projects that we can use for outreach. A good starting point is [this Notion database](https://surf-perch-473.notion.site/24c904bbbeae4545a918e1f9b3543fb3?v=c7dc3ab9665443ceab79b76f4beb589f) that we compiled for a previous research project. **Timeframe:** 2 days ### 2. Identify a list of 10-15 projects and funders for feedback sessions After the list of potential participants have been compiled, we will need to analyze member of the list on various criteria to determine eligibility, including: - Project / funder size - Project type - Funding type - Amount of funders **Timeframe:** 2 days ### 3. Schedule and execute feedback sessions Once a significant group of funders / projects have been identified, we will need to reach out and establish contact in order to schedule user feedback sessions. **Timeframe:** 1-3 weeks, depending on availability. ### 4. Aggregate and analyze feedback As we finish up our sessions for user feedback, we will need to aggregate all of our notes and compile them into digestible pieces of insights. Our goal here is to use various methods of analysis to generate specific pieces of insights to help us make product decisions. **Timeframe**: 1 week.