Topic for pre-proposal discussion: The Reference Client Roadmap and the Decentraland Foundation

Governance
1

Summary

Should the Decentraland DAO delegate to the Foundation the responsibility of developing and executing the roadmap for the Reference Client?

Abstract

The Reference Client (the app at play.decentraland.org) is currently the most widely used Decentraland client. Right now, the Decentraland Foundation is the main contributor to the Reference Client’s open source code base, but given the DAO’s ownership of the client (and the need to have the DAO approve major changes), the Foundation is hindered in how quickly and effectively it can develop new features and improvements.

To overcome this hurdle, the Foundation is suggesting that the DAO delegate the development and maintenance of the Reference Client to the Foundation. This delegation would be reviewed and renewed every 12 months. The Foundation would provide a roadmap to the DAO to review, provide feedback on, and approve on the same 6 month schedule to help communicate to the community the Foundation’s strategic and technical priorities.

This delegation would empower the Foundation to:

  • Communicate and execute a solid roadmap both for community developers and users
  • Build a richer feature set (e.g. better in-world navigation, social interaction, and content moderation tools)
  • Ensure that the client is faster and more stable
  • Improve the quality and performance of the client’s graphics
  • Improve the client’s ability to support more concurrent users

Background

To better understand the scope of this proposed delegation and the extent of it’s impact the broader platform, it’s important to define some terms:

The “DAO”

The DAO was created to help the community direct the development of the platform’s policies, infrastructure, content moderation, and smart contracts. The DAO owns the smart contracts for Decentraland’s digital assets (like LAND, Names, Wearables, etc.), so any changes made to those contracts must be approved by the DAO. Furthermore, platform-impacting decisions or changes to Decentraland’s codebase (i.e. decisions that impact the entire Decentraland community, like strategic decisions for the client) must be approved by the DAO.

The “Decentraland Foundation”

The Foundation is a non-profit organization that was formed to help protect the intellectual property of the Decentraland brand (something that the DAO lacks the legal status to do). The Foundation was also tasked with supporting the decentralization of the platform alongside the community.

The “Decentraland Stack”

Decentraland is made up of a complex “stack” of different smart contracts, protocols, and applications. Together, they make up the Decentraland Platform. Generally speaking, the different decentralized layers can defined as:

  1. The smart contracts that make possible Decentraland’s scarce digital assets (like land, estates, wearables, names, etc.)
  2. The Catalyst software used to run the distributed network of servers that host and provide content to users.
  3. The software development kit that people use to build content for the world.
  4. dApps like the Builder that allow people to create and arrange content for the world without writing code.
  5. dApps like the Marketplace that allow people to manage and exchange Decentraland’s digital assets.
  6. Clients that allow users to interact with the content of Decentraland. Decentraland clients are like web browsers (e.g. Google Chrome or Mozilla Firefox) in that they all provide access to the same network and information, but are not the web itself.

The “Reference Client”

The Decentraland Reference Client discussed in this proposal is a web based app that allows people to access and interact with content and other people within Decentraland’s virtual world. This application sits at the top of the Decentraland Stack.

It’s helpful to remember that the Reference Client does not constitute the entire Decentraland Platform, that it is just one alternative for accessing the Decentraland Platform, that anyone can develop a customized client, and that the roadmap discussed in this proposal for the Reference Client can’t dictate changes to any other components of the platform - those must still be approved by the DAO on a case by case basis.

Specification

Duration and renewal of the delegation

The DAO would delegate to the Foundation the responsibility of developing and maintaining the Reference Client for a period of 12 months, according to a roadmap approved by the DAO on a biannual schedule.

The Foundation would be responsible for writing each 6 month iteration of the roadmap, but each iteration must be approved by the DAO.

Ideation and validation for the roadmap

The DAO must have a clear path to contribute ideas and requests to the roadmap. This could take the form of a new polling category within the DAO specific to client feature requests and suggestions. These proposals could then be voted on by the community, with accepted suggestions being passed to the Foundation for inclusion in the next iteration of the product roadmap.

Deviations from the roadmap

The Foundation would be able to reasonably depart from the roadmap to make full use of the Foundation’s familiarity with the competitive market, Decentraland’s user base, and regulatory requirements, but these departures must be later approved by the DAO as part of the biannual schedule.

Funding development

Funds to develop the Reference Client (e.g. payroll for developers) would still be provided by the Foundation, not the DAO.

Termination of the delegation

The DAO may choose at any time to revoke this delegation in favor of giving it to another entity.

Limitations of the delegation

The delegation is limited to the Reference Client and does not allow the Foundation to make changes to other areas of the Decentraland platform (e.g. changes to the Marketplace’s smart contracts); any such changes must pass through a vote in the DAO.

Rationale

  1. The Reference Client is a very complex application that is relevant to the continued Decentraland platform development.
  2. The product and software development life cycle for something as complex as the client requires countless technical and strategic decisions to be made on a daily basis
  3. Given the time it takes to write proposals and pass them through the DAO, it would be extremely impractical to have the DAO weigh in on each of these decisions
  4. So, it’s clear that in order to develop the client at a speed sufficient to compete with other metaverse projects, at least some level of formal delegation is needed
  5. The Foundation is the best candidate to receive this delegation given its proximity to the platform, its resources, and its knowledge of the market and the Decentraland community
  6. The suggested delegation would provide the Foundation with the autonomy needed to execute quickly, while still being subject to the relevant decisions, directions, and control of the DAO
2

Thank you Eric for bringing this preproposal to the forum and the DAO channel to get some feedback before its put up for a DAO vote. As always, you have done a great job providing a detailed write up.

Let me start by saying that such a proposal seems very logical. The Foundation has been developing the client thus far without much input from the DAO and the proposal states the Foundation continue covering the development costs. Should every change to the client require a DAO vote, there will be a serious lack of momentum, which I don’t believe anyone really desires. In addition, while I do believe there are many active voters in the DAO who have a technical background, I do not believe most voters will allocate sufficient time to review the technical aspects and think through the implications required to scope a 6-12 month roadmap. I’ve been apart of a few dev teams over the years whose roadmaps were governed by folks unfamiliar with the work required to execute, and its not fun to say the least.

Seems to be daily that I see questions in discord from old and new DCL citizens regarding the future of the client, a desktop client, a VR client, etc, without getting the answers they seek. Delegating to the Foundation would presumably lead to a published roadmap, answering many peoples questions on what the future holds. Some may not like the answers to their questions, but at least they get closure.

I subscribe to the notion that the Foundation is building a reference client, not the end all be all of Decentraland, and that others should feel inspired to build additional ways to access Decentraland, in their own vision. In the future, should that transpire, I believe this would make the system more robust. On the most basic level, I think about it like having multiple options for cryptocurrency wallets, or even node software. So long as everyone agrees on what is considered protocol, multiple teams can work independently towards this goal. We do not have a large enough network such that protocol can be observed through consensus, nor do I believe that paradigm makes sense here. This is where the DAO comes into play.

Items 1-3 in the Decentraland stack listed above–the smart contracts, catalyst software, and SDK–fall into the category of protocol. It is important for me that this distinction remains in tact, if in fact the DAO passes this proposal to delegate the client roadmap Foundation. While this proposal is about item 6, the client, having the Foundation acknowledge that the DAO/community should play a part in approving protocol is important.

As an example of why this may be important, the sdk update 6.6.6 caused many scenes to break, without proper warning. When scenes break, there may be a loss of revenue/profit or a reputation hit. Having the DAO pass a vote to approve pull requests related to protocol is vital. Protocol requires stability and should not be rushed to change. Slowing momentum with DAO votes on protocol should be considered prudent.

All of this to say, this proposal does feel a bit like a formality, as the Foundation’s work won’t materially change with the passing of this proposal. But at the same time, it does formalize elements of the relationship between the DAO and the Foundation.

I do have some questions that would help me better understand the current state:

  • Is the DAO actually in charge of the roadmap for the client currently?
  • What would happen if the community were to vote against this now or in the future? Would the Foundation cease development of the client? Would the Foundation submit another proposal for this delegation?
  • How does the Foundation plan to use their voting power in this vote? The Foundation could easily throw enough VP behind this proposal immediately to create a voter bias or scare people away from participating…IMO, it would be good to gauge the community vote before 1-2 million VP backs the proposal. Possibly delay the Foundation vote till midway through the proposal period.

In summary, I support the idea of this proposal. I appreciate the hard work and effort put forth by the members of the Foundation. I want to see more features added to the client at a faster pace. We all stand to benefit in the short and long term. I would love to hear more opinions from the community on this, as I can only speak for myself on this issue.

Feel free to message me in discord or @ me in the DAO channel if you’d like to converse on the topic.

4 Likes
3

Hey @MorrisMustang, I’m sorry it took so long to get this response back to you. I’m glad you found the write-up informative, and thank you for taking the time to write such a great response that raises some very good questions.

I’d like to try addressing this point-by-point:

Delegating to the Foundation would presumably lead to a published roadmap, answering many peoples questions on what the future holds.

Exactly. This is actually one of the big motivations behind the request in addition to building more awareness of the various layers of Decentraland’s stack and how the DAO can interact with those layers.

So long as everyone agrees on what is considered protocol, multiple teams can work independently towards this goal. We do not have a large enough network such that protocol can be observed through consensus, nor do I believe that paradigm makes sense here. This is where the DAO comes into play.

This is so important. The different areas of Decentraland are just nuanced enough that it becomes difficult to clearly define what constitutes “protocol”. In my opinion, any change to the platform that will have immediate and unavoidable downstream impact needs to be approved by the DAO. It’s also up to the DAO to help define what “protocol” means for Decentraland, and what the best ways are for the DAO to engage with governing protocol changes. This proposal is a step in that direction.

Items 1-3 in the Decentraland stack listed above–the smart contracts, catalyst software, and SDK–fall into the category of protocol. It is important for me that this distinction remains in tact, if in fact the DAO passes this proposal to delegate the client roadmap Foundation. While this proposal is about item 6, the client, having the Foundation acknowledge that the DAO/community should play a part in approving protocol is important.

Again, I agree with this 100%. This delegation would result in the Foundation’s acknowledgment of the DAO’s role in protocol changes in addition to giving us (the Foundation and the DAO) a chance to better define what that process should look like.

All of this to say, this proposal does feel a bit like a formality, as the Foundation’s work won’t materially change with the passing of this proposal. But at the same time, it does formalize elements of the relationship between the DAO and the Foundation.

Agreed, this is a bit of a formality, but it’s a very important one because it clarifies expectations (both of the community and the Foundation) and it allows us to set some boundaries (e.g. how the community can make feature requests and how those requests should be rolled into the roadmap).

Now, addressing your specific questions:

Is the DAO actually in charge of the roadmap for the client currently?

Technically, yes, but so far no one has been able to clarify specifically how that should look (i.e. how does the DAO act on its ownership of the reference client’s roadmap?). The delegation proposal is one attempt to build that clarity by defining some concrete mechanisms the DAO can use to guide the development of the client.

What would happen if the community were to vote against this now or in the future? Would the Foundation cease development of the client? Would the Foundation submit another proposal for this delegation?

If the community were to vote down this particular version of the proposal, then I imagine the Foundation would try to identify the sticking points before submitting something more inline with what the community wants. I can’t really see the Foundation ceasing development of the reference client entirely, but without any form of delegation from the DAO, something would have to change.

It’s worth noting that the Foundation’s role in helping the reference client is not set in stone and will likely change in the future. For example, the DAO might eventually form its own product team that could set strategy for the client - thus removing the need for the Foundation’s help. Another potential is the creation of multiple widely used clients, rendering the reference client itself obsolete.

However, (for the time being) the Foundation sees itself as the most readily available org with the broader vision and context needed to help make the reference client successful. That being said, the ultimate goal of the Foundation is to provide a roadmap that best reflects what the community wants to see in the reference client - doing anything else would be counterproductive.

How does the Foundation plan to use their voting power in this vote? The Foundation could easily throw enough VP behind this proposal immediately to create a voter bias or scare people away from participating…IMO, it would be good to gauge the community vote before 1-2 million VP backs the proposal. Possibly delay the Foundation vote till midway through the proposal period.

Again, it’s in the Foundation’s best interest to act according to the DAO community’s opinion on this, so I don’t see a scenario where the Foundation “forces” this proposal through with its VP. The Foundation does plan to vote in favor of the final proposal (given its status as another MANA/LAND holding party within the community), but it will wait to vote until midway through the vote (or later) to encourage everyone to participate.

I help this provides some added detail and helpful context. Are there any specific line items or areas of the proposal that stand out as needing revising or elaboration?