# Why open-source timelines/roadmaps don't work
**URL:** https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518
**Category:** Internals & Design
**Created:** [May 28, 2023, 4:32pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518 "2023-05-28T16:32:10Z")
**Posts on this page:** 2
**Page:** 3
### Author:  [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)
#### Post date: [June 26, 2023, 12:59pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/41 "2023-06-26T12:59:33Z")
I can’t speak for everyone else but if someone creates an issue and asks about making a PR to something I maintain I’ll do what I can to support them doing so and I’m usually transparent about the difficulty and potential reception. Most people in the community don’t have a Stackoverflow attitude. So it’s perfectly fine to ask a quick question and you won’t be berated for repeat Qs.
---
### Author:  [@scelles](https://discourse.julialang.org/u/scelles)
#### Post date: [September 7, 2026, 6:48pm UTC](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518/42 "2026-09-07T18:48:09Z")
I agree that open-source projects should be very cautious about timelines and commitments. In many cases, the useful information is not _when_ something will happen, but _what problems have been identified, what solutions have been considered, and what is currently preventing progress_.
I think this becomes even more important with AI-assisted development.
We should perhaps distinguish between a roadmap and a **documented design space**. There are often many ideas that we would like to implement, but cannot yet because of a missing language feature, a dependency, performance constraints, lack of time, unresolved API questions, or simply because the problem is not mature enough.
It is nevertheless valuable to document these ideas, including approaches that were tried and rejected and the reasons why.
Today, an AI coding agent can potentially turn this kind of documentation into an active part of the project’s memory. It could later recognize that a previously blocked idea has become feasible because some dependency, compiler feature, or architectural constraint has changed.
So perhaps instead of:
> “Feature X will be implemented in Q4”
we should document something more like:
> “Problem X exists. These approaches have been considered. Approach A was rejected because…, approach B is currently blocked by…, and approach C might become viable if…”
This makes no promise about _when_ something will happen, while preserving valuable engineering knowledge for future contributors, human or AI.
In that sense, I think the “missing middle” between ideas and implemented features may deserve much more attention. AI makes maintaining this kind of project memory considerably more useful than it used to be.
[Previous page](https://discourse.julialang.org/t/why-open-source-timelines-roadmaps-dont-work/99518.md?page=2)