Cosmos Developer Onboarding

[faddat]

It seems to be an agreed-upon fact that it takes about 3 to 6 months to get up to speed with the cosmos SDK. Honestly for me it took longer.

Oh because I am working to grow a team developers that are focused on the cosmos ecosystem, right now I am thinking a great deal about onboarding. I think for some of this is very well addressed in the conversation about versioning.

I think that it may be a good idea to have a conversation about scope, as well. I made a ridiculous pull request recently, which is well it was enormous, and kind of slept all of the osmosis features into the mainline cosmos SDK.

Key questions

• should modules, as they become more mature, move toward the SDK, instead of remaining in their own repositories?

I'm thinking about Linux kernel modules when I mention this, by the way. And probably everybody knows but I'll run through the way that things are handled in Linux, basically, modules live outside of the kernel repository until they are mature. When they are considered to be mature, they are mainlined. When code is mainlined, the kernel team takes responsibility for its maintenance.

I think that right now, compatibility is unclear and discover ability of existing modules is pretty low. From talking with various people in the ecosystem, it seems that the vast majority of people are really enthusiastic about seeing their modules used in other projects-- they want the security/reliability that comes from wide usage.

• This repo contains the easiest to discover set of modules that exists; should it be expanded?

• What is the boundary of the SDK, with respect to scope?

• What else can be done to improve developer experience?

Let's walk through the initiatives that we can currently see underway, and if you're aware of others, please let me know, I'd like to add them here.

1. Starport: I think that starport has dramatically improved developer experience for all of cosmos, and that we should continue to view it as the proper starting place for an IBC-enabled cosmos application.
2. Semantic Versioning: After reading through @gsora 's thoughts on how to accomplish this-- and the reasoning, I can totally get behind the idea of starting at 44.0.0 and working forward from there.
3. Code-gen client libraries: CosmJS, the vuex generator in starport, and the dart client library generator in starport come to mind first here.
4. go-relayer: The strangelove team has some great DX improvements in mind for the go relayer, and I think this will help to improve the overall adoption of IBC.

---

Additional thoughts:

• Segmentation -- we've got it already, but imagine that you do not have experience with Tendermint, Cosmos, Starport, or even blockchain. You now need to model in your head:
  • p2p
  • deterministic everything for the blockchain
  • what is a genesis file
  • construction of a validator ecosystem
  • proof of stake
  • the major cosmos SDK modules
  • software interfaces that do indeed get a bit arcane, and are sometimes unwieldy (Websocket, I'm looking at you)
  • economic model for the blockchain
  • there's more, and if you reply I'll go ahead and add it to the list

Compare this with putting an ERC-20 contract on BSC, ETH, or Tron, and I think that this gives some idea of the challenges that we face.

NB This post here is a thought exploration-- I explicitly do NOT know all the answers, and I am TOTALLY posting to get people's thoughts and ideas.

[jackzampolin]

Thanks for opening this topic @faddat. Will also post a comment about building clients in go and the compounding issues facing new SDK devs especially from the client side.

#7448 (comment)