I think turning some JuliaCon talks into blog posts could be good too. More searchable and probably gets a wider audience. I also personally prefer to read, I find easier to go at your own pace than with a video. Is there some good way to encourage that or help make it happen?
22 Likes
That may be because there is no unified direction that everyone is going. How could that even happen, with a FOSS project?
Even in a large company, there will be no single direction that everyone is going. Of course reports and communications may try to paint a different picture, but that is usually just public relations, not reality.
This sounds a bit hypothetical. I also get the feeling that you are interested in a specific feature (static compilation, deployment, …), get you are asking a generic question. Perhaps you would get more satisfying answers if you simply asked about the state of the feature(s) you are interested in, rather than a generic unified roadmap, which very clearly does not exist in the sense you are describing it.
10 Likes
I wonder if there are ways to encourage collaboration implicitly. For example, if there were a forum category where one could express the intention to create a new package, it would be possible to get prior feedback and avoid developing a new one without realizing that similar packages already exist. Although developing Julia is more complex and requires more resources, I wonder if a similar solution could be feasible.
1 Like
Huh? More complex and requires more resources compared to what?
A Julia package
Oh, I thought you meant “developing [a package/script] in Julia is more complex…”. Got it now
2 Likes
Governance is not only about the current state but also about shaping the future, as it ultimately makes decisions that define the project’s direction. That said, I agree that this might be somewhat out of place in the current context.
I don’t fully agree that the solution is simply to create more materials. In fact, I believe the opposite is true — the materials will come naturally once there’s a centralized place for creative contributors to share and develop them.
For example, some might remember the Doggo Dot JL YouTube channel (https://www.youtube.com/@doggodotjl). I still don’t know who was running it, yet they created videos about my packages completely on their own. This shows that creative contributors will produce materials spontaneously — as long as they have access to clear, centralized information (the person used our documentation and examples). You should not underestimate the amount of creative people who want to do videos, but they need a source of information to do them!
I was not trying to suggest that PEP actually announcing those plans. PEP is a reference to a good working model of organization. PEP does provide is a structured, central space for ideas and directions. A single No GIL PEP generated hundreds of YouTube videos, blog posts, and podcasts. That happened organically because people had one clear source to refer to. I will repeat, but I don’t think the goal should be to produce more scattered materials when the real issue is that the existing information is fragmented. If we bring everything together in one place, it becomes much easier to see which ideas are gaining traction and what directions are being explored.
Right now, some discussions happen on GitHub issues, others on YouTube or HackMD, and it’s nearly impossible to get a coherent overview.
A centralized process would:
(a) make it clear what’s currently on the table,
(b) make it easier to assess which ideas are getting attention, and
(c) make it simpler to infer Julia’s overall direction based on that momentum.
So in the context of “2, 5, 10 years plans ahead” question - a single centralized place makes it easier to infer such plans and direction. Yes, PEP doesn’t publish those plans, but simply based on the traction around No GIL PEP you could infer that it’s happening soon and that is a priority at the moment (along other things).
That said, I agree with @ChrisRackauckas that we need to start somewhere. I like the idea from @mbauman of asking core developers about their plans for 2026 and making that visible — perhaps as a blog post on the main Julia website. But ultimately, I think the goal shouldn’t be to produce more content, but rather to establish a centralized system for documenting ideas and directions, similar to the PEP process.
Please lets no do that. Julia deserves to be great today. We don’t need to wait X amount of years because someone did that. Lets make it better. Lets not wait.
I don’t agree that having a central organization is unnecessary. This isn’t about development being easier or harder; it’s about clarity and prioritization. Even if something is technically easy to do, it’s still important to know whether it’s considered a priority. That’s not a technical issue but an organizational one.
Some people have already said that I can already find the answers I’m looking for. And yes, I can and in fact I do know many answers — but only because I’ve spent a lot of time searching.At the moment, I often find myself asking around about specific topics I’m interested in, which is inefficient for everyone involved. I also never suggested this information, direction or plans do not exists. I will repeat, but my main concern is that the information is too scattered, making it unnecessarily difficult to find. Many people won’t make that effort and may move away from Julia for long-term projects simply because they can’t easily see where it’s heading. The PEP process is a proven model for how such a system of directions and priorities can work effectively, but it doesn’t need to be an exact copy of course.
It’s a bit discouraging to see arguments against such an approach. I don’t see any major drawbacks to making Julia’s development process more transparent, structured, and centralized. Once we have that foundation, new content will naturally emerge.
13 Likes
An additional point about “just creating more materials”. Personally, I’m not a fan of podcasts — they’re simply not my preferred format. Some people enjoy them, and that’s perfectly fine. But if certain information is available only as a podcast, I (and likely others) will miss it entirely.
With a centralized place for ideas and directions, creative people can still produce podcasts, videos, or blog posts — simply because they enjoy doing so, just like Doggo Dot JL did. The key is that Julia doesn’t need to manage or encourage content creation directly; it just needs a central hub for collecting ideas, outlining the roadmap, setting priorities, and defining long-term goals.
Making a podcast first - is an inverted process. Make the information about a particular feature easily accessible and in one place first - and podcasts about that feature will emerge automatically. In addition to a podcast other types of media will emerge too - some prefer videos, some prefer text.
15 Likes
Yes, would you like to help lead the effort to create it?
The point is, it’s easy to get someone to jump onto a call for 30 minutes, then have AI generate a transcript and generate a blog post, and edit it for 5 minutes. We can do that for 50 core devs in one month and then we will have the centralized repository. Do you want to help me do this? Or would you prefer interviewing and then writing text? I wouldn’t have the time to write that much but if you are willing to do that part then let’s go!
8 Likes
Come on, It is extremely hard to do lol 
5 Likes
I’d be happy to help with creating the “Plans for 2026” blog post, based on initial input from core developers about what they are currently working on or planning for 2026. We could start by publishing a first collection of these ideas and plans as a post on the main Julia website. From there, we could either build a dedicated website or add a new section to the existing one to begin collecting JuliaEPs for new ideas. Unless there’s significant resistance from the core developers at this early stage (which I hope won’t be the case), this could serve as a great first step toward a more structured and transparent process.
Are all the top contributors (ok lets say top 50 as you suggested) is good enough to be qualified as a core developer? Or that might be out of date?
6 Likes
What I meant: priorities and direction, that means trying to predict future, or simulating such predictions, that may be difficult or senseless for many reasons discussed above.
As for governance - it exists de facto, of course, though in distributed and arguably not well-defined form. Thus it is possible so describe the actual current state. That kind of descriptions do exist (the post above by mbauman is actually is one), just scattered and incomplete.
IMO having kind of up-to-date description “Who is Responsible for What in Julia Ecosystem” in one place is doable and would be helpful.
That’s probably out of date since it’s all time, and the most active people now are not necessarily the people who were active 10 years ago. Maybe @jameson @kristoffer.carlsson or @jeff.bezanson can help compile a list of folks to track down? The start of the list is probably, hitting compiler + standard libraries:
- Jeff Bezanson
- Jameson Nash
- Kristoffer Carlson
- Cody Tapscott
- Gabriel Baraldi
- Keno
- Stefan
- @tecosaur 's REPL stuff?
- Claire
- Diogo Netto
- Erik Schnetter
- @mbauman
- Steven Johnson
- Dilum?
- Andy Dienes
- Oscar
- Ian Butterworth
- Mose
- yuyichao
- Lilith
- Jakob Nissen
That may include some people who are not as active in Julia Base / standard libraries, it’s just a list off the top of my head and I don’t work on the julialang/julia repo, and if someone was left off it’s not a snub it’s just a start to the list and probably biased towards the people I talk to more / work in areas closer to what I use.
Maybe we take this to a hack.md and continue from there.
6 Likes
Something related to this conversation (that I probably should have mentioned earlier) is another one of my projects that’s fighting for my time: GitHub - JuliaLang/devguide.julialang.org
In particular, see this (incomplete) page: Core Developers · Julia Developer's Guide
Fleshing out the dev guide would be great IMO, I’ll just need to borrow someone’s cloning machine (or if people ~20x my donations, work on FOSS full-time ).
In the meantime, PRs would be brilliant.
6 Likes
I would also like to see a roadmap like this one of Typst.
Here’s an open upload link. How about we try to make it (name, github account, area)? I’ll do the first one but need to catch a train.
Let’s get it started and then I think if we have 80% of it folks will help finish it and we can get it into the docs. I’ll spawn a claude bot to try and find any missing names 
2 Likes
Great start, I can compile an email to each of them somewhere next week.
I think we can start very simple, I referred to PEP multiple times, but actually I like Rust RFC better in terms of simplicity. Simple sidebar, simple pages. Introduction - The Rust RFC Book
Can also use Documenter.jl in the same fashion, simple sidebar, simple pages with references to issues and PRs. Very simple to add new pages.
@tecosaur Actually checked your website second time and maybe its indeed a great place to start, needs a bit of a cleanup and ready to add new RFC. On the other hand might be limited in terms of inferring the traction, what people are interested in, no comments section. Needs a bit of brainstorming
1 Like
@mbauman, I recall you(?) once put together a more detailed list, just cannot find it. Could you probably link it here?
this is a good summary of the things we are discussing here hehe
5 Likes
Actually I asked Gemini Pro to help me finding it. That was the response 
:
I’m having a hard time fulfilling your request. Can I help you with something else instead?
Could it just be my personal hallucination?
2 Likes