Autark's Status Report & Retrospective On Flock

I was going to wait to post this until after we launched Open Enterprise, but it seems it should be shared now.

Autark’s Status Report

Review the a status report for features that are being developed by Autark and its partner Open Work Labs on the AGP-19 and AGP-73 grants received from the Aragon Network.

Retrospective

There are a few lessons learned from our experience of contributing to aragonSDK and Aragon app development. These were valuable lessons. Learning from these will make the program stronger going forward.

Lessons learned about day-to-day development processes

As Flock developers, we need to pay close attention to the aragonSDK enhancements being actively developed by Aragon One. This means:

  • being more attentive to the updates discussed in All Devs calls and check-ins
  • keeping up to date with the active branches and PRs in Github
  • and most importantly – having conversations on architectural expectations before we begin developing enhancements

As a network of Flock teams, we should have more conversations about priorities and roadmaps so there are clear expectations with when a feature or app is expected to be released. This is especially important if delivery is dependent upon the client’s release schedule.

As developers, we should avoid developing “workarounds” in our apps because a feature isn’t available in aragonSDK, as these may not be backwards compatible with enhancements being developed by the maintainers of aragonSDK. Instead we should think about the aragonSDK changes first and develop our apps using more sustainable methods (so future enhancements don’t break our apps, such as the frontend event triggers issue).

Some of the lessons above may be “no-brainers”, but developing software in a decentralized network and utilizing a nascent technology stack that is constantly changing (week by week) is not something that has much precedence. Just like Tesla spends most of their time optimizing not the car, but the factory that makes the cars, we should invest more time optimizing the process of cross team collaboration. This will allow us all to allocate our scarce resources (time, capital, emotional energy) more effectively. This will result in better products and experiences for users.

Speaking of users, Autark’s apps have started to gain traction in many active organizations. There are also many potential future use cases on the horizon - be it for AGPs, events, hackathons, and more. Open Enterprise has served as a promotional vehicle for Aragon - being demoed to potential users during onboarding processes, events and conferences such as Web3 summit. Additionally, the early adopters have squashed bugs and provided feedback for improvement. It’s essential that development teams can coordinate so that things like this are possible. At the moment this momentum of people being able to use our current Rinkeby apps has come to a halt because of the breaking changes introduced in 0.8. We need to maximize our synergy so that small teams can effectively allocate their resources and the entire ecosystem can be better because of it.

Lessons learned about Flock initiatives and repo management

It was a bit rushed to include repo management requests in AGP templates. We were not fully prepared for what that really means and what the expectations are to actually receive that privilege. It does not make logical sense for ANT holders who are not involved in development to decide who has the ability to merge code.

But what this does mean instead is that the Flock teams need to be aligned on initiatives that require a time investment from both sides, hence it actually makes more sense for product decisions to be determined outside of AGP voting processes. AGPs should be used to guide high level decisions, but the day to day grind of executing on those decisions should be left to Flock teams or the Product Working Group, which can include other community members.

And due to this lesson, it leads to another lesson we learned from our first AGP: do not include initiatives that require work or dependencies on aragonSDK unless there are clear commitments from maintainers to prioritize them. This means that it is not logical for the Aragon Network to decide these types of initiatives in AGPs, because we are still too early as a program to determine how to manage this. This is not the fault of the maintainers. Autark submitted our AGP-19 proposal last minute, and it got approved. We designed that process internally based on our own goals and ANT holders approved. We then encountered a challenge: fitting Autarks vision and into the client’s roadmap. This will most likely result in some changes to the original proposal, but this is essential. With everything still in early beta, and as the first team test driving the Flock program, we need to be able to adapt and evolve. Ultimately, this does not change the spirit or vision of our proposal, but it does highlight that the Flock program and inter-flock collaboration has a lot of room to improve.

What is most logical to me is using a combination of ANT voting with surveying tools for prioritization to gather the sentiment of users, and working groups for inter-Flock negotiation and consensus. The early vision of the Aragon Cooperative was aiming to set an alternative approach for product development, but that experiment didn’t take off well for reasons that are too deep to get into in this thread.

The overall strategies outlined in Flock proposals are essential to help ANT holders understand the vision of a team. This is a vision. As such it has not yet been realized. We are still trying to find product/market fit. We are still trying to figure out decentralized governance. We are still trying to figure out decentralized collaboration on an intertwined roadmap. An initial proposal is just that, an initial proposal. Having at least a three month roadmap per team should be something we strive towards. We need to make this more transparent for all of the products and components we are working on. Autark is actively working on improving transparency in our product development beyond our blog updates. We hope that the community can provide constructive feedback to help us prioritize our client-related work. This will allow us to focus on shipping the features people really want, and to do so in a way that aligns with the client roadmap of A1.

In addition to our own efforts, we think the Product Working Group will vastly improve how Aragon develops products as a network. The kick-off just happened today! As part of that endeavor, we may want to consider ramping up the human resources for the Flock program to improve coordination between teams.

We are so grateful to be a part of this path, this mission. We look forward to your feedback, however critical it may be, and thank you again for supporting us along this journey. We’re all fighting for freedom, and we couldn’t do it without the support of the Aragon project, the founders for deciding to implement such a revolutionary program, and the community support.

Thank you

6 Likes

Love the spirit and direction this post lays out!