Starting this thread to discuss what Project Quiver may look like after the current funding proposal expires at the end of February.
As currently planned, we’ll end February with a complete and document dev-kit drone design, as well as a number of drones built and ready to be given, sold, or loaned out to developers who may want to develop something on top of the platform.
For the future scope, I’d prefer to reduce the DAO’s investment in design and testing on the main platform. Now that the product is designed and built, we shouldn’t have to spend so much on the project going forward. We can shift to supporting the drone, addressing any bugs or issues that arise.
I think that we should focus on growing the community and ecosystem around Quiver. We can loan out our assembled dev-kit drones to people that have a good attachment/use idea and are capable of developing further. We could run contests, grants, and bounties around our attachment ideas and things that we want to see build on top of Quiver.
I think it’d be good to have a budget to support shipping the dev-kit loaners and funding those grants/bounties/contests. I think we should also have some funding to make sure we have engineers available to support developers as they fly and build on top of Quiver, but ideally our documentation should reduce the need for real time support to developers. I don’t think the Project Quiver needs to have people on hourly commitments to work on developing attachments/features directly. I’d rather shift that to a grant/bounty approach. We could have people on commitment time working to recruit developers and administer the grants and bounties.
As we continue to grow the ecosystem, we will hopefully see demand from people who wish to purchase Quiver to use as a product. In that case, the project can expand to work with onboarding and supporting manufacturers who can build and sell Quiver at a larger scale.
What do you guys think? How do you imagine the project looking as we go in to the future? I’d like to be conscious of Arrow’s limited budget and make sure we use it efficiently.
This approach sounds perfect to me. If we find that developers/users need more real time support down the line, or Quiver needs a significant update, then we can always adjust accordingly.
I am not sure if this is the place for this specific of a question but, how many people/roles do y’all think we will need to have on commitment for admin, support, and refinement of Quiver?
What do you mean? I think we can incentivize “beta-test” items with grants/bounties just like attachments and other features. We can loan out the dev-kit drones to anyone who wants to work on test flights, obstacle avoidance/other testing too. Like Zeynep could add items to the bounty board for specific test flights in certain conditions or with config changes to improve performance or test limits.
I think the project/product will feel like it’s in “beta” stage indefinitely - until there’s enough features and interest to justify a manufacturer putting in the effort to bring it to more of a “product” stage with greater availability and production. It might be hard to put a specific timeline on that since it does depend on outside/organic factors. To give that outcome the best chance, we can focus on incentivizing what we believe to be the most widely interesting and important features and use cases. Maybe the beta testers themselves would want to turn a feature into a service business - then they could buy or build more drones for their business. This is what is happening with Javelina Works in Texas. If we continue to do well here, we’ll be needing a lot more Quiver drones and that’d justify a more serious manufacturing push.
I’m thinking maybe two or three people - part time might be enough. It’d be a good exercise to list out the expanded ongoing tasks to keep on commitment for this project vs what can be a good bounty or grant. Some that I’m thinking of:
Test flight/user support. Work with users or developers using the drone and help them through configuration changes, setup, basic repair, etc. Would include reviewing ardupilot data too, so at least some of this would have to fall on Zeynep. Hopefully we can get our docs to an excellent state to where this role isn’t needed as much, but I think they’ll have to evolve over time as we work with new people using the drone. We probably won’t get it right the first try. I think Errrks would be good at generally guiding users and integrating their feedback into the docs
We’d have to recruit users, testers and developers too. I think that’s probably some balance of visibility work - excellent photos, website, Arrow socials, photo and video content. And then some targeted outeach - like posting on reddit or reaching out to notable people in drone communities on twitter, youtube, etc. Docs will be super super key here. Someone getting a cold DM or seeing a reddit post will probably immediately click in to the docs to understand more, so whoever is working this role would have to really be thinking about docs from more of a public facing/into approach instead of strictly technical docs. Updating them based on initial feedback and questions from people who first hear about Quiver and Arrow. I think you and Sleety would be good at this but will probably need help from someone closer to the engineering to answer some questions and have technical conversations.
Bounty/Grant/Contest Administration. We’d have to come up with the most important features/attachments/test campaigns to incentivize, and then vet and work with the applicants and recipients to make sure they have what they need to work on the project and deliver on their work. Deciding on the incentives should be a collaborative governance activity for all of us, but it’d be good to have someone on commitment working to come up with ideas and detail out the bounties/grants.
Ongoing engineering support. If there are any crashes or bug reports, we’ll probably want some people to do more detailed analysis or design improvements as necessary. This would be more focused on the base drone, attachment work can happen via bounties/grants.
In general, I agree with the direction mentioned, though I often have a feeling that some aspects are still a bit unclear and will only define themselves over time.
Regarding the community expansion: I think we have to be realistic that at 25kg, Quiver is outside the usable range for most hobbyists in terms of price, size, and regulations. It will be difficult to get the masses on board early on. That’s why I see the cooperation with Javelina as the perfect example to follow. I think we should put a lot of work into finding 3-4 professional key partners similar to them. We can work with them to configure Quiver for their specific needs and help kickstart their payload development. This validates the platform much faster than waiting for individual developers.
I fully agree with the importance of documentation, especially regarding the Payload SDK. As long as that isn’t simple and understandable, the hurdles for people who want to develop attachments are just too high, and our support team will be overwhelmed with basic questions. A great target for us would be to produce a YouTube tutorial showing the live development of a simple attachment based on the finished documentation. If we can show that process clearly in a video, we know the platform is ready.
I also still have some concerns regarding the legal roadmap, specifically for Europe. A 25kg drone faces strict regulations here. Without working toward basic certification or standard compliance, professional companies effectively cannot use it, and we would be limited primarily to the US market or hobbyists who build everything themselves. Since the drone hasn’t been checked against international engineering standards yet, we need to be aware that this process consumes time and resources.
One last point: how do the other projects (Spearhead, Feather) fit into this new picture? If the goal is to be attractive to investors, I understand that a broader portfolio helps. But on the other hand, developing multiple airframes is expensive. I think it would be risky to take resources away from Quiver too early. Quiver is at a good first stage to be deployed, but there is still plenty of development needed to make it truly market-ready. So, at the moment, I still have a big question mark over how we balance that portfolio vision with the reality of our current budget.