Intro
Polkadot was built on creating a decentralized blockspace-centric infrastructure for applications to be built on top of. This results in a fruitful ecosystem of key players that must work together for the greater good of the ecosystem: parachains, infrastructure providers, wallet providers, end-user app developers, the developer community, and the general community, among other participants. In such ecosystems: “The whole is greater than the sum of its parts.”
PaperMoon, a core Developer Relations contributor to Moonbeam for almost four years, recognizes the intricate dynamics and understands the major pain points (as an ecosystem team) of being part of a highly diverse ecosystem. Our proposal is focused on enhancing collaboration, knowledge-sharing, and overall efficiency for all ecosystem participants.
Consequently, through the W3F Decentralized Futures program, PaperMoon seeks to expand its team to provide specific Ecosystem Developer Relations (Ecosystem DevRel) solutions targeted at Polkadot ecosystem participants. The goal is not to provide general Developer Relations services to external teams but to focus on addressing Polkadot’s unique needs, always from the angle of an ecosystem team. Consequently, the Ecosystem DevRel team will offer solutions that bridge communication gaps, enhance understanding of key features and how to apply them, create a knowledge-sharing platform of tools and SDKs that lack proper documentation, and streamline developer feedback processes, with the ultimate goal of reducing the friction for developers who want to build and are currently building on Polkadot.
As Dr. Gavin Wood said, “You need to make it functional right so it has to actually do something that’s useful for people”.
We appreciate the valuable insights the community can provide on our proposal. Constructive feedback is vital in enhancing our proposal to serve the Polkadot ecosystem better.
But First… Who Are We?
If you just heard about PaperMoon (site under construction) for the first time, don’t worry. PaperMoon has been working quietly “behind the scenes” in the Polkadot Ecosystem for almost four years.
In 2023, Moonbeam made strides towards decentralizing its development, moving from a primary core contributor providing all services (PureStake) to a cohort of multiple teams, where each provides expertise in a specific area. PaperMoon was founded by Alberto in January 2023 as the Developer Relations contributor to Moonbeam. Since July 2023, it has operated as a separate entity offering Developer Relations as a service for the network. Moreover, PaperMoon has been an early Developer Relationship contributor to Tanssi since the project was founded in May 2023.
Alberto joined the Moonbeam team in June 2020. Besides Moonbeam, he has been actively involved in Polkadot-related activities such as the Polkadot Assurance Legion, Polkadot educational series, and online and in-person meetups organized by ambassador communities. He has done many Polkadot-specific presentations for events (Sub0, Decoded, ParisDot, EthDenver, EthCC, LisCon, Token2049, SmartCon, and others), hackathons, community meetups and ambassador groups in USA, Europe, LATAM, and APAC.
Even though PaperMoon was founded in January 2023, part of PaperMoon’s stellar minds have been with Moonbeam from the beginning, in Developer Relations and Developer Community-oriented tasks. Consequently, the team is well aware of Polkadot and its entire ecosystem and has collaborated multiple times with many external teams on Polkadot-related activities and meetups.
Summary of the Problem Being Addressed
This proposal is content that results from gathering feedback from many ecosystem participants such as parachain teams, wallet providers, service providers, core developers, W3F technical educators, Polkadot Blockchain Academy contributors, members from Parity, and community members.
All of the ecosystem participants shared similar conclusions: there are many friction barriers when building in the Polkadot ecosystem.
Some of the key aspects can be summarized as follows.
Technical How-Tos on Key Features
Teams have very little information to prepare them when implementing core flagship functionalities like Crowdloan, XCM, Asynchronous Backing, and Polkadot <> Kusama bridge, among others. Consequently, core ecosystem developers must painstakingly study the core logic to understand the changes and successfully implement multiple tests to add new runtime features. This increases engineering overhead and delays new feature releases. Parachain core devs can, without a doubt, accomplish all of this. However, the current process does not always respect their time, energy, and resource allocation.
Lack of a Knowledge-Sharing Platform and Proper Documentation for Ecosystem-Generated Tools
Today, ecosystem teams can’t find reliable and up-to-date documentation on features built and developed by other ecosystem participants. For example, if ecosystem teams try to use tools like Chopsticks and Zombienet as testing frameworks, they will struggle to find adequate documentation on both tools. This creates a high entry barrier for teams that are not familiar with such tools. For example, wallet teams could use Chopsticks-based forks to test new implementations like XCM transfers, and native staking, among others.
Other examples include the XCM-related library created by the Moonbeam team or how to use other tools like xcm-emulator properly.
No Documentation on Best Practices for Polkadot Developers
At the time of writing, only two teams in Polkadot (Moonbeam and Bifrost) and four teams in Kusama (Moonriver, Bifrost, Picasso, and Crab) have adopted OpenGov, clearly indicating that there is a high barrier to entry to implement the core flagship features, such as this more modern mechanism of on-chain governance.
One core reason is that there is little to no documentation on what best practices to use when building on Polkadot, from building a pallet to implementing an existing pallet, using XCM, and using Polkadot.js SDK. Teams are often either just guessing or learning by doing.
Consequently, ecosystem teams find a lot of friction when trying to do any of the actions highlighted before. For example, OpenGov was introduced in Kusama around November 2022 and Polkadot around June 2023. Ecosystem teams often see it as complex. When Moonbeam implemented it, the team spent a fair amount of time understanding the voting mechanisms and deciding on appropriate approval/support curves. There was a huge amount of engineering work with no clear guidance. Implementing it created a lot of overhead for the engineering team and product, developer relations, community moderators, and other Moonbeam community members.
Lack of Proper Documentation on Polkadot-SDK Releases
At the time of writing, the now-named Polkadot-SDK has had approximately 150 releases since August 2019. While some of them are relatively small, there have still been three releases per month since the first one! The pace isn’t the problem; rather, the lack of guidance and clarity comes with these regular releases, forcing devs to catch up constantly.
Many ecosystem teams (especially parachain developers) experience a common pain point: the engineering overhead generated when trying to stay up-to-date with Polkadot-SDK releases. For smaller teams, this impedes innovation, as most of their engineering resources are dedicated to staying current with the latest releases.
Moreover, many PRs often have misleading labels that don’t necessarily assess the impact of a specific feature on parachain teams. The Moonbeam team has been impacted by this multiple times. For example, a PR to Polkadot related to OpenGov introduced an unexpected change in Kusama that affected many parachains. Nevertheless, this PR was labeled as having a “Low” impact.
Lack of Hackathon Scoping around Core Polkadot Tech
Hackathons are one way to bring new developers to the Polkadot ecosystem. In 2023, Polkadot hosted approximately 16 hackathons with at least nine different partners.
Polkadot has relied on external partners like AngelHack, DoraHacks, EasyA, EncodeClub, HackerEarth, OneBlock+, and others to organize hackathons. These partners do well on the execution front. Still, there is a lack of technical understanding of Polkadot to distinguish it from every other blockchain and coordinate all ecosystem teams under a unified hackathon theme that can result in a successful event. Moreover, they must coordinate with each ecosystem team separately, creating a lot of overhead when organizing a Polkadot-related hackathon.
Throughout 2022 and 2023, PaperMoon (through Moonbeam) participated in many Polkadot-specific hackathons, which lacked clear guidance and cohesion from a technical perspective. Hackathon organizers, in conjunction with hackathon execution partners (mentioned before), did not do a good enough job on topics, either focusing on generic topics that are seen in many other blockchain ecosystems like “Smart Contracts” or “NFTs” or technically complex and niche topics like “Runtime building.”
Lack of Proper Feedback Loop Channels
In Polkadot, it is quite common that feedback to the core Polkadot/Substrate developers is given either through GitHub or, in some cases, the Polkadot Forum. Moreover, feedback is somewhat unidirectional, meaning that the ecosystem participants provide some feature request often addressed or incorporated based on its relevance and alignment with the overarching development goals, without a continuous dialogue or iterative exchange between core developers and ecosystem participants.
While these feedback channels work, they heavily impact the speed at which the ecosystem can evolve, limiting the reach and real impact that feedback can have. It also creates a recurring problem: ownership of ensuring that feedback is received and handled.
Furthermore, there needs to be more prioritization of what is needed from the ecosystem developer’s perspective. This harms the adoption of key Polkadot-specific technologies like XCM.
The Proposed Solution
As outlined above, developers’ challenges when building in the Polkadot ecosystem call for a comprehensive and tailored solution.
To tackle the identified issues, PaperMoon will establish a dedicated team of DevRel Engineers. This team (Ecosystem DevRel) will address the challenges described above, always focusing on the ecosystem team’s perspective.
The team will prioritize the following key areas.
Key Features - Documentation and Knowledge-Sharing Platform
The Ecosystem DevRel team will develop comprehensive documentation (or revamp/repurpose existing ones) around key features and how ecosystem teams can interact. This includes features (but is not limited to) such as XCM, Asynchronous Backing, Core Times, OpenGov, and more.
To do so, the Ecosystem DevRel team will do a combination of active and passive outreach and connect with ecosystem participants on an ongoing basis to understand the status of the ecosystem from their perspective and to prioritize what features need to be documented based on demand. In collaboration with the W3F technical educators, this documentation can be hosted in the Polkadot Wiki so that it is coherent with ongoing structure and can benefit from things like SEO and Polkadot’s reach.
With this strategy, on the one hand, the active outreach mechanism ensures that the Ecosystem DevRel team is constantly reaching ecosystem participants to inquire about the new features they want/need to be documented. Conversely, the passive mechanism ensures that the ecosystem participants and core protocol developers can request certain features to be documented or submit updates to the documentation.
Tooling, Scripts, and Procedures - Documentation and Knowledge-Sharing Platform
The Ecosystem DevRel team will use established communication channels with ecosystem teams so that the tools they create can be shared broadly with other teams building on Polkadot. In addition, all tools will be well-documented, and the DevRel team will ensure the documentation is always up to date.
To do so, and similarly to the point before, the Ecosystem DevRel team will use multiple channels to empower teams to showcase new tools so that the Ecosystem DevRel team can work on documentation for it.
Like before, the Ecosystem DevRel team will operate a passive and active mechanism for this documentation, ensuring that up-to-date documentation does not necessarily require ecosystem teams to reach out or submit the PRs themselves. The team will be responsible and accountable for maintaining the documentation up-to-date as long as the tools/scripts work.
Best Practices - Documentation and Knowledge-Sharing Platform
The Ecosystem DevRel team will ensure there is a source where ecosystem players, including Polkadot core developers, can document (or provide the necessary details so that the Ecosystem DevRel team can document) best practices when building on Polkadot. This does not necessarily have to be for parachain teams, but also developers building infrastructure or services.
To do so, the Ecosystem DevRel team will first connect with all ecosystem participants to understand the current needs of the ecosystem and create a priority-based system to address all requirements. Ideally, the Ecosystem DevRel team can leverage DevRel members from the ecosystem teams or a key contact if there is no DevRel position to address their needs and what needs to be properly documented regarding best practices.
Moreover, the Ecosystem DevRel team can invite Parity core developers to share their tips on different aspects when it comes to implementing certain pallets and substrate coding best practices, among other things.
Polkadot Release Knowledge Center
The Ecosystem DevRel team will work with the Parity release team to understand new releases and help ecosystem teams with the upgrade.
To do so, the Ecosystem DevRel team will plan to schedule regular meetings with the Parity release team to ensure that the core changes of the release are well understood from an ecosystem team perspective.
Once the key points have been identified, they can be shared with all ecosystem participants through public good channels like a Telegram channel via a Bot or posted in a specific DevRel ecosystem knowledge-sharing center section.
Hackathon Coordination
As Polkadot is a fairly complex ecosystem with many moving parts, we believe Hackathons should be coordinated with the help of the Ecosystem DevRel team. The team can focus the hackathon on concrete topics that generate interest in key technologies unique to Polkadot and cater well to different buckets of developers: newcomers, dApp developers, smart contract developers, and blockchain developers. Some examples include:
-
Showcase Specific XCM Use Cases - XCM is widely underutilized in Polkadot. 90%+ of XCM messages transfer tokens between the different ecosystem participants. Moonbeam utilizes some remote EVM calls via XCM, while Oak Network arranges automation executed through XCM. With technical expertise and input from ecosystem teams, concrete XCM use cases can be offered to hackers to experiment and showcase. For example:
-
Allow users from different parachains to interact with specific functionalities from other parachains without switching wallets. For example, a game on Moonbeam, HydraDX’s AMM, and Bifrost’s derivatives, among others
-
Modify existing wallets so that they are cross-chain aware and capable of handling the wallet owner’s computed origins accounts on other parachains
-
Create a voting mechanism that uses Manta’s privacy layer in which tokens are routed through Manta and then used to vote in a privacy-preserving way
-
-
Create a unique XCM use case that utilizes technology from at least 2 parachains
-
Tooling, Services, and Data Analytics - Polkadot does not only need runtime developers, it also needs people who build tools and services around it. Topics around these areas that are bound to specific Polkadot features like XCM and on-chain Governance can help attract developers
-
Polkadot for newcomers - Create bounties specific to developers who want to learn more about Polkadot and its core technologies. For example:
-
Create a library that interacts with a specific Polkadot flagship product like OpenGov. The idea is that developers learn about OpenGov and how it works, and create simple tools that can help teams: a monitoring mechanism for proposals, a way to track voting tendencies, and a delegation-specific dashboard.
-
Create tools that can load-test ink! based smart contract networks by targeting specific contracts and function calls.
-
The Ecosystem DevRel team will help organize Polkadot-specific hackathons around ecosystem teams. Moreover, the team can target specific hackathons organized by external ecosystems through partners like EthGlobal. For example, we propose that Polkadot participate in the hackathon component of DevCon 7 2024, which will be hosted in Thailand at the end of the year. Participating in external hackathons is crucial to bringing new developers into the ecosystem, and giving Polkadot exposure to developers from other blockchain communities.
In addition, the Ecosystem DevRel team will provide active support to hackers, challenging them on ideas they want to build, and providing solutions to problems without requiring ecosystem participants’ engagement. They can provide a unique view that is more “ecosystem” centric.
Hackathon coordination will be a joint effort amongst other key players, to ensure it is a coordinated ecosystem-wide effort and boosts visibility and brand awareness. Therefore, hackathon coordination will be a joint effort of the Ecosystem DevRel Team, marketing, and community.
Ecosystem Feedback Loop
The Ecosystem DevRel team will support and assist with feedback from ecosystem participants. The team will use the existing channels (GitHub and Forum) and create new ones through the ecosystem Knowledge-sharing site, or direct communication channels with ecosystem teams.
More importantly, the Ecosystem DevRel team will own the different feedback streams, ensuring they reach the corresponding stakeholders and set recurring meetings to review all the open topics. The team will produce monthly/quarterly reports to ensure the entire ecosystem has visibility into the general feedback of the ecosystem.
An extremely important need is a feedback loop and “owner” from an ecosystem perspective. Polkadot and its ecosystem must cater to smart contracts, dApp, and runtime developers. From an external perspective, Polkadot is seen as an extremely difficult tech to build on top of (not only runtimes!). Therefore, feedback is crucial to ensure other devs have a pleasant experience when building products on top of the Polkadot ecosystem.
Next Steps
We plan to submit our proposal once we’ve gathered enough feedback from ecosystem participants.
If you want to reach out directly, feel free to do so at Telegram: Contact @albertov19
.
