HausDAO.DevRel.PROGRESS_REPORT_01
1. Objective
The Developer Relations workstream (manned by @ui369.eth and @arentweall ) have been auditing our current developer experience (DevX) and interviewing community developers interested in building with DAOhaus. We interviewed 6 teams (e.g. Plaza, Nestr, Sobol, Karma, Guildxyz, Hedgey) and studied our previous integrations with developers. Mainly, our findings pointed to 2 questions:
- Developer Personas: What are they building? Why work with DAOhaus?
- General Feedback: How has the experience been so far? Any feedback?
2. Who are they?
Most teams are solving specific and well-defined problems above the governance layer, such as task management, token-gating or reputation models. They are early-stage startups that are iterating heavily on their product, aspiring towards product-market fit and traction.
Some teams are building on-chain solutions, while the rest are solely off-chain. Generally, crypto-native problems and solutions (e.g. timelock escrows & reputation) require on-chain solutions, while more traditional or Web2 solutions (e.g. task management) stay away from smart contracts, etc.
Here is a summary of the teams we talked to:
| Name | Problem Space | Stage of Integration | |
|---|---|---|---|
| 1 | Plaza | Service Agency | To be explored |
| 2 | Nestr | Collaboration | Integration in progress |
| 3 | Sobol | Collaboration | To be explored (Summon) |
| 4 | Karma | Reputation | Integration in progress |
| 5 | Guildxyz | Token Gating | Possible in next 3 months |
| 6 | Hedgey | Escrows & Lockups | Integration in progress |
3. Why work with DAOhaus?
Broadly speaking, all softwares have the following components:
- Application: Everything that makes the software useful (e.g. application logic, program, middleware and infrastructure)
- Data: A record of all interactions from the application
Developers will work with another software if their application or data creates a better user and/or developer experience. Through our interviews, these are a few models and reasons why developers would like to work with DAOhaus.
3.1 Partner Integration Models
Projecting into the future, all 4 models will be important to DAOhaus as well as our partners.
| Model | In the long run, this becomes important because… | |
|---|---|---|
| A | Partner reads our data | partners want to surface contextual DAO data in their applications |
| B | Partner writes to our application | partners need entry points to DAO governance (e.g. giving shares from a bounty board or NFT marketplace) |
| C | We read partners’ data | this will help to create a better user experience on DAOhaus as other developers build primitives (e.g. identity, reputation, etc) that add to DAOhaus functionality |
| D | We write to partners’ application | partners will want easier ways to interact with other dapps and protocols trustlessly through their minions. |
3.2 Prioritization & Recommendations
As of today, models A (Partner reads our data) and D (We write to partners’ application) are the areas we should be prioritizing today. These 2 models have (1) existing demand and (2) existing infrastructure, allowing us to achieve meaningful success with the resources we have today.
| Model A (Partners read our data) | Model D (We write to partner’s application) | |
|---|---|---|
| Existing Demand | As mentioned, most DAO tools are still early-stage and sorting out product-market fit in their own problem space (e.g. reputation / task management / etc). That remains their first priority. Some of these tools now have traction in their core product offering, so the next step is to surface contextual DAO data that can enrich their user experience. |
The early-stage nature of these DAO tools mean that these DAOs want more usage and traction on their contracts and protocols. If they are targeting DAOs, the DAOhaus application is a good platform for more users to use their products / protocols. |
| Existing Infrastructure | Today, these developers can query our Subgraph APIs for this data. With our current infrastructure, we already enable this use case - this process is easy to access. | Today, our recommendation for these developers is to create custom proposal forms (i.e Boosts) through DAOhaus. With our current infrastructure, we already enable this use case - this process is difficult to access. |
Given the above, DevRel team will focus on existing demand and existing infrastructure (i.e. Models A & D) by creating better developer documentation, tooling and engagement. As the magesmiths are shipping future infrastructure (i.e. v3), we will be providing inputs for v3 infrastructure to magesmiths, while keeping external developers updated.
4. How has the experience been so far?
4.1: Partners are unclear how they can integrate / work with DAOhaus
DAOhaus is largely an open-source project that embraces other developers integrating and building on top of our application, infrastructure and data. With this, we welcome developers to build “anything they want” like a blank canvas.
This creates 2 issues:
- Emergence & openness in how developers can work with us creates ambiguity. To work with external developers, it is often easier to illustrate possible use cases and integration modes, so they can envision what works best for their application.
Recommendation: Going from “build-anything-you-want emergence” into more well-defined integration modes, we can create developer interfaces, documentation and tooling to evangelize, educate and onboard developers on DAOhaus.
- There are actually some areas we want to own, but we have not aligned internally on our approach vis-a-vis external developers. These include Boosts vs Bolt-ons (how do we enable external developers who want custom UIs), payment rails, marketplace and curation mechanisms). When developers have a blank canvas, they will gravitate towards larger problems to solve (i.e. the above issues).
Recommendation: Producing a map of what’s allowed & not allowed will help give greater clarity, save time and avoid disappointment & tension for external developers.
4.2 Developing Integration Categories
As we are embracing composability and building developer interfaces, we will need to be clear about the developer personas, their problems & their expectations of a “good” solution.
Who are our users? What problems are they solving? What primitives do they need?
Answering these questions will help identify partners, prioritize resources and scope out requirements and start execution.
Recommendation: Identify areas of strategic importance & create clear products and interfaces for external developers.
The end goal would be to reveal our developer-facing product offerings and value proposition with the aim of making them understandable and accessible.
An example would be Chainlink’s product suite below. They have clear use case categories, even though most of the products share the same underlying infrastructure.
4.3 Four Integration Models
Since developers have shown demand to work with us in the above 4 models, we can assume there are valid problems to be solved here. Hence, we could adopt the 4 product strategies / lines below.
“To better understand these 4 product lines, it’ll be useful to dive into the target audience, problem, solution and revenue model (see below for sample)
A. Data Feeds and D. DAOhaus as a Platform seems to be the closest to consumption and usage by external developers today. This is because the existing infrastructure has already enabled developers to read data or build Boosts.
From an execution point of view, DevRel will continue to improve DevX for today’s MVP versions of Data Feeds & DAOhaus as a Platform. On a longer time horizon, the magesmiths team will have these 3 product lines in mind while designing developer interfaces in v3, so that we can provide the most optimal Data Feeds, Embedded Governance & Platform product”
Recommendation: Magesmiths aligns on the above 4 categorizations. Existing development timelines can be revealed through this lens to improve developer interfaces and experience.
4.4 Developer documentation & tooling can be improved
Our current resources for external developer integration can be improved. Today, developers need to understand, navigate and work on the DAOhaus codebase instead of working on packages, APIs and SDKs provided by us. Imagine being teleported into a strangers’ kitchen and being tasked to cook dinner without knowing what ingredients & appliances are available, where to find them, what works and what doesn’t, etc. Developers are having a similar experience with our code base.
The creation of custom forms have made things easier, but there is still a big barrier to developers integrating with us. We should take these into account when building for v3 developer interfaces.
Recommendation: In the same vein as prioritizing existing demand & infrastructure, the developer relations team will improve developer documentation for v2, so that these developers can better understand and navigate our stack to build what they need. This includes more explainers, tutorials and samples to achieve common modes of integration.
We have been already executing on this workstreams and aim to publish the following in the next 2 weeks:
- 1x text-based tutorial to build a boost (inspired by Jord’s workshop on the Mint a Million Boost, see here for current progress)
- Broad documentation improvements: Conceptual Overviews & Explainers
We will then seek developer feedback with these updates.
4.5 Developer engagement & support can be improved
Previously, as DevRel did not have dedicated focus and support, there was feedback that the developer support was intermittent, causing a loss of momentum and progress in some projects. This will be improved with UI369 and myself looking after developer engagement.
Recommendation: DevRel to improve developer support & enablement
Initially we will continue to have more high-touch developer engagement to gather feedback, gauge interest and provide support to enable developer success. In the short run, the focus here is NOT to create processes & engagement strategies for developers en masse.
We want to be grounded in helping existing developers achieve success with existing infrastructure This includes bi-weekly check-in calls, ad hoc support and regular feedback sessions on developer documentation.
5. DevRel Summary
5.1 Looking Back: Progress Update
To close off this discussion, we wanted to take stock of our progress & some focus areas moving forward.
| S/N | Focus Area | Progress (Forecasted by end June) |
|---|---|---|
| 1 | Improve DevX | Audit: We have audited the docs and are on track to completing the following docs improvements Docs Improvements: |
| 2 | Engage Community Developers | We created a CRM with 10 developer teams and ran developer interviews with 6 of them. The findings have been published above and will inform our developer relations efforts moving forward. |
| 3 | Deliver 3 Boosts | Currently, there are 3 developer teams who are integrating with DAOhaus and we will assist them in going live. (Karma & Nestr consuming our data feed, as well as Hedgey building a boost). |
| 4 | Gather feedback for v2/v3 compatibility | We did not explicitly talk about v3 requests, but we gathered more general feedback on our developer product offerings which should be helpful for v3 nonetheless. This is an ongoing workstream. |
5.2 Looking Forward
Moving forward, based on the current obstacles, tensions and objectives, this is how DevRel could potentially support our priorities moving forward (of course, subject to change)
| Focus Area | Tentative Deliverables | Tentative Timelines |
|---|---|---|
| 1. Improve DevX & increase adoption on existing infrastructure (i.e. MVP for Data Feeds and DAOhaus as a Platform) |
|
July - Aug 2022 |
| 2. Support the product strategy & developer interface design in v3 |
|
July - Aug 2022 (Maybe announce something at MCON?) |
| 3. Create DevX foundations for future infrastructure (i.e. v3) & increase adoption for all products (Data Feeds, Embedded Governance & DAOhaus as a Platform) |
|
Sep 2022 & beyond |
Followup questions for Magesmiths / Warcamp:
What is the product strategy that DAOhaus wants to own?
What are some primitives / interfaces we want to enable developers to build?
Which features of V3 can begin to involve our developer ecosystem? (development, integration, requirements gathering?)
This discussion should help us address:
- Partnerships / B2B aspirations for sustainability / strategy
- Composability aspirations for v3
- Revenue model & value accrual