Polkadot Developers

Ecosystem
1

It has now been one year since the development of Polkadot underwent a major transformation. Three distinct repositories were merged into one repository now called Polkadot-SDK, also referred to as the monorepo.

While the term Substrate might be familiar to most of you, it might not be to others who are just getting started with Polkadot. In fact many ecosystem resources still refer to Substrate which could lead to confusion especially if one doesn’t know about the history of changes. Added to that, a lot of these Substrate resources are outdated or no longer maintained.

As part of the Product Engineering team, in close discussion with the Runtimes, Parachain teams as well as the W3F Education team I think that branding is important and when done with purpose can yield great returns over time.

The following post is to discuss the following proposed changes:

tldr

We aim to:

  • Rename the GitHub Substrate Developer Hub to Polkadot Developers (check it out here: Polkadot Developers · GitHub, content still pending) :white_check_mark:
  • Rename the PJS Extension to Polkadot Developer Signer :hourglass_flowing_sand:
  • Rename DotApps/PJS Apps to Polkadot Developer Interface :hourglass_flowing_sand:

In order to:

  • Craft branding that is more targeted for all things related to Polkadot Developer tooling
  • Normalize how we name things in the ecosystem and kickstart a cleanup of unmaintained resources that still refer to the Substrate brand
  • Discuss ways to incentivize this effort and orchestrate the effort in a meaningful way

Renaming the GitHub Organization: The importance of Branding

Branding essentially provides a surface for joint efforts to stick on, for a message to resonate: Polkadot is the best ecosystem to build on in Web3.

In order for this to be self-evident, we have to put in place the right venues for the branding to be visible. I think that renaming the GitHub organization for “Substrate” to “Polkadot Developers” is a crucial step in reinforcing the Polkadot brand. It aligns most of our user facing development efforts under a single, recognizable name, reducing confusion and creating a clear, unified message.

Don’t make me think

In his brilliant book, Don’t Make Me Think, Steve Krug emphasizes the importance of intuitive design in user experience. The same principle applies to developer experience. Our goal should be to reduce cognitive load, making it easier for developers to navigate our resources and start building.

By consolidating our repositories and improving documentation under the Polkadot brand, we eliminate unnecessary complexity and indirection. Developers shouldn’t have to think twice about where to find the tools and information they need; everything should be logically organized and immediately accessible.

These efforts are completely aligned with what ecosystem teams are preparing in terms of revamped documentation and more, with a new GitHub org it will be easy to direct developers to a single place with up-to-date stuff.

Time to working example

What will the new GitHub organization contain? The Polkadot-SDK organization will be the go-to place for everything a developer needs to start building on Polkadot. It will include a comprehensive set of tools, libraries, and examples that demonstrate best practices. The goal is to minimize the time from onboarding to having a working example running.

Incentivizing participation and curation will also be key. We think that introducing a system where contributors can earn rewards for maintaining high-quality documentation, creating useful tutorials, and helping other developers troubleshoot issues will be essential. By fostering a collaborative environment under one coherent umbrella, we can ensure that the resources in the Polkadot Developers organization remain up-to-date and valuable to the community.

Other ecosystem approaches

Solana, for example, has successfully built a strong brand by focusing on developer experience and community engagement. Their GitHub organization is well-curated, with clear documentation, up-to-date examples, and an active community of contributors.

Check it out: https://github.com/solana-developers

We can learn from this approach by adopting similar strategies in the Polkadot ecosystem. By creating a welcoming, well-organized, and rewarding environment for developers, we can attract top talent and foster innovation within our community. This will not only strengthen the Polkadot brand but also ensure that it remains the leading platform for Web3 development.

Goals:

  • Rename “Substrate Developers Hub” into “Polkadot Developers”
  • Archive / clean-up old resources
  • Establish a plan for what goes in there

Why stop at GitHub?

Quantifying the results of a rebranding will take time and effort. This is why we’re shoe-horning 2 other things we will rename.

The Extension

We will rename the PJS Extension into Polkadot Developer Signer and make that visible here: Polkadot-js extension, manage accounts for substrate based chains

The page will also follow the new polkadot.com branding as well as introduce a way to redirect to ecosystem wallets.

Goals:

  • Nobody installs the Polkadot Developer Signer by mistake anymore
  • Resources that link to the Signer won’t break, but when people land follow the links by mistake, they’ll still be able to escape.
  • Influence the relative ranking of the extension compared to ecosystem wallets, without completely nuking it: it’s okay if it ranks high as long as people know not to use it

DotApps

This is a crucial application in our ecosystem that we’re currently maintaining. It is commonly referred to as PJS API/PJS Apps or other less flattering names.

The different names as well as the technical skillset required to use this application reliably led to a lot of confusion as well as users submitting the wrong thing.

The interface is intimidating but familiar to developers, this is why we’re renaming it to Polkadot Developer Interface.

Goals:

  • Clear naming of what it is: something for developers
  • Similarly, ecosystem resources linking to it will still work, but calling it a developer interface will make it evident in tutorials that they are aimed at developers and not users.

Addressing community requests

This initiative has been a long time coming and we’re glad to say that we’re almost there.

Over time, the community requested us:

  • To clarify the messaging around the PJS extension and PJS Apps and ensure it’s not on the critical path of onboarding new users to Polkadot. In other terms, our beloved PJS extension shouldn’t amongst the first results for “Polkadot Wallet”, here is one such request.
  • Unmaintained tutorials lead to confusion and are doing us a disservice. The community brought up valid concerns here & here. These issues are mainly stemming from unclear ownership and expectations for the Substrate related things.
  • … and lot more data points as well as anecdotal evidence from X/Twitter, like in this video here :fire_extinguisher:.

The rebranding will allow initiatives to attach themselves to a common place on GitHub where the community can work together towards improving things. Similarly, this will provide a clear messaging for non-devs that land on one of the applications or links: “This is something for developers”. I also personally believe that renaming the PJS family of utilities into “Polkadot Developer Signer” and “Polkadot Developer Interface” will provide a more dignified place for these essential tools in our ecosystem, as it’s safe to say that most developers in Polkadot today started with these tools.

Polkadot: The best place for developers in web3

Decentralization doesn’t equal fragmentation and lack of curation. We hope that providing a sensible branding geared towards developers will yield good returns that compound over time.

In the end, purposely crafted messaging will beat scattered efforts any day, any time. Polkadot Developers will reinforce the branding over time and is an incentive in itself to keep up-to date, as it’ll be more likely visible and associated with Polkadot, than Substrate.

By being more intentional about how we name things and how we craft the onboarding into the ecosystem, we can start working on reducing friction and improving user UX and developer UX.

Please leave a reaction or a comment if you agree with our plan or even if you don’t. Have a lovely week :hugs:

28 Likes
2

Fully support these changes, thanks for driving them! :saluting_face:

1 Like
3

Well thought and articulated, thanks Karim.

2 Likes
4

Hi @Karim!

I love seeing some discussion about updating these resources.

I was wondering if you have been working with Papermoon? They seem to have some ideas about how to move forward and seem to be making progress on a new Developer Hub outlined here

As you eloquently put it, “Decentralization doesn’t equal fragmentation.”

3 Likes
5

Hey @hippiestank -

We just connected with @Karim and are working with W3F and Parity to create a new site that will hopefully aggregate everything developers need to start building on Polkadot.

We are wrapping up a few things and will provide a second update hopefully by the end of next week.

The idea behind a Polkadot Developer Documentation Hub is to create a place to document everything for Polkadot developers, avoiding many different resources that create fragmentation (not only for consumers, but also from a SEO perspective)

Will keep everyone posted

5 Likes
6

Hi @hippiestank !

Thank you very much and of course, as @albertov19 puts it, we’ve been in discussions to ensure there is no double work and most importantly that we’re moving in the same direction as effectively as possible. :v:

2 Likes
7

While this is an expected development, I wonder if this isn’t another opportunity being missed? Specifically, the tighter grip on Substrate.

Substrate maintenance is has mostly explicit visible costs, and mostly implicit invisible benefits. Hence, almost everyone reflexively sees Substrate as a net burden - compare the push-back that greeted the crippling strike with what now greets the coup de grâce:

https://forum.polkadot.network/t/psa-parity-is-currently-working-on-merging-the-polkadot-stack-repositories-into-one-single-repository/

Given that there are several networks that now build on Substrate, perhaps the more effective way to reduce the maintenance costs of Substrate is to free it rather than consume it?

The first step would be to further distance Substrate from Parity/W3F/Polkadot. This precludes those networks from construing any approach as an effort to have them subsidise Parity/W3F/Polkadot. How is this best done? An new foundation is overkill. But a new Github org and branding seems sufficient: open-web3-stack · GitHub

That being done (unless the admins there object), the next step remains: This is for Polkadot and Kusama to each establish a model/pattern of conduct they’d like the other networks to emulate. This can be as simple as establishing a fellowship position dedicated to the org, initially PT, and a Treasury monthly budget for docs, tutorials, issue curation, triage etc. The Fellow’s initial task is to ensure the budget is spent - hint: beggar-thy-neighbor does not lead to more people thinking “Ok, that sounds like it is worth my time”… when you have multiple people wanting to work on something you’ll find what they offer to do improves.

Those two steps are obviously in the opposite direction of where you’re currently intended to head. But they are simple, and signal to the other networks there is neutral ground - kinda like the Linux kernel is to distro’s.

Related:

8

I wonder if this doesn’t encapsulate the many of the current problems. Some observations:

  • You’ll only know if Polkadot is the best place when you see how other networks use Substrate. Imagine that Solana had built on the above open-web3-stack Substrate - right now you would be thinking of pivoting to provide more of the features in the Solana offering (hint: they are not winning mind share because of their dev web site)
  • “…yield good returns that compound over time” said the Linux kernel devs never. Much of the hand wringing I see appears to be driven by the current tokenomics. That is unfortunate, but is still a choice (albeit difficult to overcome).

Right now it looks like Polkadot has either breached the breakdown boundary, or is oscillating around it… for all the usual reasons a company fails, bad management, bad board, weak product, better competitors, change in consumer tastes etc. etc.

Right now you need to be creating more options not locking them out.

9

Hello Mark, always a pleasure to chat, I enjoy reading your perspective on things. You bring up interesting points that I’m happy to elaborate a little bit on.

I did not make a mention of maintenance costs in any of my arguments, my point is about branding effectiveness.

In fact I’d argue that the implicit invisible benefits of Substrate maintenance you’re mentioning are localized to the teams using Substrate and do not benefit the broader Polkadot ecosystem a tiny bit. A name change could alleviate this without introducing any technical friction nor antagonize our unwavering commitment to open-source.

I’d even push it a bit more by saying that invisible benefits are worth very little compared to explicitly mentioned and repeated benefits. Repeated benefits do contribute to mind share and to reinforcing the message that Polkadot has indeed great tech.

A hundred teams building using the open-source Polkadot-SDK is a much stronger message than two hundred teams building using Substrate. The explicit connection between Substrate & Polkadot is not evident for people outside of our ecosystem which we we need to optimize for too. One shouldn’t have to resort to the Wayback Machine to understand that these two are connected.

For a message to stick it needs to be evident, repeated and most of all simple to remember & articulate.

You’ll only know if Polkadot is the best place when you see how other networks use Substrate Polkadot.

The best marketing for the Polkadot-SDK is done by people actually using the Polkadot-SDK and talking about it: beyond the technical specs, habit & social copying are also drivers for adoption to keep in mind.

Lastly,

Given that there are several networks that now build on Substrate, perhaps the more effective way to reduce the maintenance costs of Substrate is to free it rather than consume it?

A rename to Polkadot is much more time efficient than what you propose as a solution for this, which sounds to me as a nice thing to do but with no timeline or tangible expected benefit for Polkadot in sight. I also fail to see why the treasury should be involved here in maintaining Substrate tutorials and docs instead of just Polkadot tutorials and docs. The Substrate repo is a public archive for a year now and the data doesn’t show anything substantial happening around it or any of its forks.

In times like these I believe that consolidation and consistency of the messaging will prove to be the most effective strategy, as it allows us as an ecosystem to focus our resources and reinforce our core strengths by providing clarity and stability on what we control. Similarly, we can keep looking for points in the system where the smallest change has the biggest effect, this rename could (perhaps?) be such a thing.

There’s a saying that says that a person who chases two rabbits catches neither, and I think it’s applicable here. Priorities are key, after all we can only act upon what we control: market swings and externalities are unfortunately something we can do nothing about, but perhaps the Linux kernel devs know something that we don’t? :disguised_face:

1 Like
10

Not necessarily it’s aimed at developers or for developers. It’s widely used by non-devs as well. Renaming to developer interface will further reduce the scope of the platform. I think we should find a better alternative names than limiting it to developer interface

Likewise for this.

11

This is one GREAT LEAP FOR POLKADOT :partying_face:

1 Like
12

I think this is exactly missing the point of the rename.

Yes, many non-devs use Polkadot JS Apps, and then they say that UI/UXs in Polkadot suck. It was never designed to be a tool for pretty much anyone other than Developers. The problem is that it took us a while to get to actually high quality wallets and UIs like what is provided by Talisman, Nova, Polkadot Cloud, etc…

By labeling things as “developer interface” we do not limit access of these apps to anyone, but at least remind them they are playing with low level tools.

3 Likes
13

I think we diverge on objectives.

I’m making the case from a blockchain maximalist position rather than trying to maximize the uptake of any one operator.

Remember DOT is <cough>not a security<\cough>…
It just happens to have holders who talk and act as if it is. That, pinky promise, is pure coincidence. :wink:

14

Security status is irrelevant–this is not the “Blockchain Forum” but the Polkadot Forum, and the expectation is that discourse here is predicated on a shared desire to elevate, improve, and empower Polkadot.

15

Is it?
To my mind it creates incentives that apparently influence proposals such as this one:

I’m a huge fan of securities and how they incentivize proposals such as this one. I also can recognize when they generate negative externalities - which I pointed out.

Yes, but there is some overlap such as what this proposal seeks to do - further ingest Substrate.

I believe what I proposed enhances Polkadot, you may not agree, e.g. encourages more of the networks to carry some of the Substrate maintenance burden - @Karim clarified that the Substrate maintenance burden is in no way driving this proposal:

I had made the observation that branding isn’t the problem, and won’t rehearse them again.

16

I don’t mean to discredit your opinion, but I believe this might just be rooted in your misunderstanding of the expression in this specific context, perhaps due to occupational/work bias. The claim is not that renaming the GitHub organization will somehow influence the DOT price, this is absurd.

The returns I’m alluding to are less fragmented documentation and resources, that build up on each other under a common umbrella called Polkadot Developers. Just as a planet orbiting multiple stars can lead to an unstable system at the slightest nudge, brand fragmentation can lead to long-term instability and negative effects: What is Substrate? Why are all the GitHub links archived? Why are there no updates on the repos? How does it relate to Polkadot?

I postulate that having a single name under which ecosystem resources and developer tooling can reside, the branding “Polkadot Developers” will help with discovery, reduce confusion and avoid duplication of efforts. As Shawn puts it correctly, this also serves as a way to set expectations. This will furthermore reduce the “abandonment effect” of Substrate: the data point I’ve shared is that while it being open-sourced, not much has happened over the year to maintain it.

This is directly opposed to a fragmentation of time and effort under different nomenclatures that compete for attention.

I had made the observation that branding isn’t the problem, and won’t rehearse them again.

Duly noted. However, I believe we’re addressing different problems, which is perfectly fine as it leads to interesting dialogues. That said, I will gladly further engage with hypotheses substantiated with data, especially if they are directly actionable. I must admit that I still fail to see how your proposal moves the needle and in which direction it aims to do so. Maybe that’s my bias. :v:

1 Like
18

I think this is a pretty essential initiative. Im in full support. From the PJS perspective, IMO it’s a no brainer to rename the extension and apps to be more developer driven. The philosophy of Apps has always been a testing playground, and a low level UI for on chain interactions. A majority of the actual features and functionality in Apps has no merit for the average base user, and therefore would be enough evidence for me to support the migration.

In terms of the extension, there are way more UI/UX driven solutions out there that are user focused, whereas the polkadot-js extension is a simple “airgapped” (in quotes) extension that really caters to developer workflows.

Overall, I am happy to be apart of this, and help push it forward on the PJS side.

5 Likes