Hi all!
Apologies for the delayed response here, I was on vacation. I’m happy to see that we’ve been able to reach a consensus on a path forward. I wanted to drop some general thoughts here and call out some next steps I think we should take…
From this discussion, I see there being three main questions/themes that need to be addressed:
-
What’s an Org? How does the Radworks ecosystem support the emergence and growth of development teams outside of our current Orgs? Which teams should remain grant-funded, which should become Orgs? Why?
By dedicating time to defining what Orgs are, their purpose, and their role in fulfilling the Radworks mission, we can gain a deeper understanding of how to effectively guide and nurture emerging contributors within the Radworks ecosystem.
-
What is the role of the Grants Org in the Radworks ecosystem? As @bordumb wrote, the “goal of maintaining an ecosystem grants program is to attract & onboard contributors to the Radworks ecosystem”. I think this process has made us realize that this can be interpreted in multiple ways. For example, it can mean contributors developing new technologies (e.g. other than Radicle and Drips) and/or contributors developing around Drips and Radicle. By further clarifying what the ideal end-state is for new grantees from a Radworks perspective and what is needed from grantees from a Radicle & Drips’ perspective, we’ll be able to specify this
diagram with criteria and expectations that will make it easier for the Grants Org to coordinate their objectives and allocate their budgets.
As @fintohaps pointed out, this will help us decide if a tighter relationship between our product Orgs and Grants is necessary. If the goal is to onboard new contributors to the Radicle and Drips ecosystems, should Radicle and Drips be be scoping work/RFPs for the Grants Org? Should they be supplying mentors? Should they be reviewing applications? After clarifying the goals of the Grants Org and its role in the Radworks ecosystem, we can revisit these questions together and ensure that the Grants Org is being set up for success and maximum efficiency.
-
What work currently lies outside the purview of Radicle and Drips purview that can (and should) be effectively taken on by external teams? It seems like there are differing opinions about what work is required when and why. In Radicle’s case, even though it seems we agree that there’s value in “filling the gaps” with Grant-funded work to support adoption and onboarding of Radicle v1.0, we’re having trouble figuring out what work should be prioritized and when. I believe this is because Radicle Org is lacking a clear “go-to-market” plan for the Radicle v1.0 launch that identifies target users, communities, and organizations. Having a collective sense of who we want to onboard to Radicle will give contributors like @yorgos and co. a better idea of what to build and when. We all want the same thing: get people using Radicle. I believe adding some structure and approaching the GTM problem collectively will make it easier for a healthy open source ecosystem to form around the Radicle Org.
In terms of next steps, I think it would be a good idea to collectively focus on #1 and #2 while the Radicle Org ships Radicle v1.0 and @yorgos and co. focus on their upcoming grant work (Radicle CI Integrations - #4 by yorgos — Exciting!). I think the best way to move forward is to start a new post diving into these topics and host a group call to discuss. @shelb_ee and I will take lead on that. After that, we can revisit Radicle Developer Tooling specifically and strategize on what is the best way to support this work moving forward.
I appreciate everybody’s patience and participation in this discussion and the one previous 
Looking forward to seeing this proposal make its way the Submission phase next week.