Questions about ROADMAP.md

[mishmosh]

Thanks for the recent updates to https://github.com/libp2p/js-libp2p/blob/main/ROADMAP.md for 2024-2025 — the first amongst libp2p implementations to update in the past year 🎉. A few people at Devcon asked me about the libp2p roadmap. I wanted to point them to this doc (and the same for other implementations) but I think it's missing some context and detail. A few suggestions and requests:

1. User-friendly summary. This currently feels like an internal planning document, not a roadmap for users and potential users to skim. Can this start with a paragraph of context and direction?
2. Reducing jargon. Instead of "Productionization" what about a more straightforward term like "Developer and Deployment Tools", "Developer Ergonomics", or something else?
3. Timing and expectations. In cases like "the milestone is to ship a POC" it would be great to unpack it in plain language, e.g. "The goal is to ship a POC by mid-2025."
4. Cross-implementation compatibility. Add a dedicated section about interoperability goals with other libp2p implementations (Go, Rust, etc.)
5. Community input and collaboration. How should people chat with maintainers or give input on this roadmap? Are there any parts of the roadmap that would benefit from community contributions?

[achingbrain]

Thank you for your comments.

User-friendly summary

We tried to keep the exposition to a minimum but perhaps the opening paragraph could be improved. Would you like to open a PR with some edits?

Reducing jargon. Instead of "Productionization" what about...

I dislike verbising so I do agree though I don't know if the suggested alternatives cover that section well as a theme. I resisted the urge to put Does exactly what it says on the tin as I don't think the phrase travels well 😅, but the idea is that we want to dogfood more and ensure everything works reliably and predictable even under heavy load. This would mean that users are then delighted instead of surprised.

Part of that is improving observability via more metrics (for node/electron) and devtools (for browsers/mobile) and while doing that we'd likely uncover inefficiencies in resource usage that can be addressed.

Timing and expectations

This is intentionally vague because it's hard to guarantee the amount of developer time that is available. Funding appears precarious and developer goodwill is hard to rely on so any predicted delivery dates would be inaccurate. I don't really see how we can do any long term planning at present.

Cross-implementation compatibility

Compatibility is foundational in all pieces of work, nothing would be accepted that broke interop and all features should be tested via the interop suite, the transport-interop suite or test fixtures at a minimum. Any accidental compatibility regressions would be addressed with maximum priority.

That said there weren't any specific work items for interop that came up in the discussions.

I tried to start a thread in #libp2p-implementers about trying to coordinate roadmaps between implementations more generally and is likely where interop things would come up (slack link) but I didn't get much of a response.

Some of the most impactful libp2p developments have occurred in the least amount of time when the different implementations have had their goals aligned so I strongly agree this should be addressed though I'm open to suggestions as to how. Developer meetings, or even if the libp2p foundation just had themes in mind that they want everyone to work towards, that would be helpful.

How should people chat with maintainers or give input on this roadmap?

The PR that added the roadmap was open for almost a month and all feedback received during this time was addressed.

Additional feedback can be given by opening PRs to the roadmap or starting a discussion.

Are there any parts of the roadmap that would benefit from community contributions?

Community contributions are certainly welcome on everything at all times. The first thing for a contributor to do is to get in contact, either start a discussion or join the maintainers open meeting to discuss what they'd like to work on and their maintenance plan for anything delivered.