As it is usually the case with a technical community, many people here can’t understand the business implications of not having a clear project roadmap. This terrible situation we have with Julia affects the growth and adoption of the technology in industry.
If Julia never gets out the “JuliaHub” umbrella with a proper governance model that is more aligned with other open source languages in the market, then
Investors will never feel safe to put money into it.
Companies will never feel safe to adopt it in long-term projects.
The language will be suffocated in the hands of a few players.
Major tech companies like Google and Microsoft will never look at Julia with different eyes if it is this tiny project governed by a few individuals who can’t let it grow without their total control.
@bvdmitri and I run businesses that are entirely based on Julia stacks, and we are naturally concerned with the trends we are seeing. So please don’t suggest things like “pick another language if Julia doesn’t suit you at the moment”. It is very frustrating.
If a roadmap existed that is independent of JuliaHub’s agenda, it would be much easier to fund external contributions and to show the world that the language has a very long future.
I think you are too focused on JuliaHub as a governance bogeyman. JuliaHub is “just” another business that is based on Julia stacks and is invested in the success of the language — much like your company. It has no special authority with respect to Julia language development.
Many JuliaHub employees, in their individual capacities, together comprise the core development team of Julia and have a lot of influence about what gets worked on and what gets merged. But this is a property of those individuals and not a property of their employment status at JuliaHub. Those individuals would continue to be influential, keep their merge rights, etc. if they were to go work at another company.
You can’t assert that without a decentralized governance model. The real world doesn’t work like that, unfortunately.
There is enough evidence that JuliaHub has a disproportional weight in the direction of the technology and that is fine. The governance model and roadmap just keeps things under control with basic rules about what gets merged, closed, who is in the committee, etc.
Try to think outside the box. The community includes people with other types of expertise beyond core language development. Consider investors willing to put money in the features they deem most relevant in their industry. They could easily pay salaries to external contributors that are not even using Julia at the moment if they see a clear roadmap and a small chance that the work will get merged with decentralized review.
If you start to think of scenarios where JuliaHub competitors have money and human resources to further develop the language, you will also need to think how that would play out without a governance model and roadmap. People in company A could easily shutdown an initiative from company B if it compromises their business. You can’t be naive when money is involved. This it not a purely technical discussion.
JuliaHub is indeed a relatively bigger slice of the pie funding Julia development, but frankly, that’s just a reflection of Julia’s low adoption, not any gatekeeping. SciML is somewhat independent, but it supports JuliaHub products and has overlap with JuliaHub leadership. There’s nothing stopping other companies’ employees or even volunteers from getting deeply involved in core language development or, more often, developing their own projects and products. On the latter note, it’s not realistic for various companies or countless volunteers to agree on communicating 1 roadmap for all projects, nor would it be useful for any interested parties to read a source bogged down by the entire ecosystem. PEP certainly isn’t the place to read about the direction of SciPy or JAX.
JuliaHub’s products are attracting money to Julia development to begin with. Investors might also fund external contributors that offer separate standout products or prototypes. While I agree that each project should communicate a roadmap to the public, it won’t convince people to give money to external contributors who have no significant involvement in Julia development, organizations, or products. If I had a million dollars and someone told me they read a lot about JuliaC and can make a pull request to complete the rest of the to-do list in this year’s JuliaCon talk, I’m not giving them a cent until they’re vetted by committed JuliaC developers, many of whom are on the JuliaHub payroll.
Fragmentation is only part of the frustration. paulmelis made a good point about the JuliaC repo making implications about its usability status at most. The Youtube archive of JuliaCon talks is technically centralized, but it’s countless videos clipped from streams, many of which are about the broader ecosystem, not the core language. The State of Julia doesn’t talk about it, which is understandable because no 40-minute talk can or should cover every development in the core language. If you search “JuliaCon 2025 JuliaC”, you get this nice talk about JuliaC examples and its current limitations, but not really anything about its development. The actual talk is State of --trim, and the term “JuliaC” is not present in the video’s title or description. While I think the scope and benefits of roadmaps were sometimes exaggerated in this thread, it really shouldn’t take me this many clicks to find information on the very first point of the 1.12 release highlights, and it’d be far more convenient in a readable format.
However, it is somewhat tangent to the topic. I think it would add some context on how Julia is developed vs Python, because even simplistic statistics such as the distribution of PR contributors across organizations show a drastic difference between Python and Julia. I will not draw any conclusions. I was just curious who actually are julia developers :).
I loaded all open PRs for each language and mapped each PR creator to their first organization listed on their GitHub profile page. If I was unable to obtain this information from the GitHub API, I considered the user Independent.
What does that mean? What’s the order of the organisations? For all I know (which is nothing) that’s next to random.
Organisation membership can be hidden, and that’s hidden by default. However JuliaLang members are encouraged to make it public, because that information is used for running PkgEval and other related tools, so there’s a bias there. I have no idea of whether member of the python org have similar technical advantages in making their membership public.
I don’t know if it’s random or not. Can you point me to the GitHub docs about that? But if it’s uniformly random that there will be no significant bias made by the organization order, right?
And I do not have answers about python organization.
What surprised me, to be honest: Actually, why don’t we see any PRs opened by JuliaHub devs, defining a JuliaHub dev as someone who has JuliaHub (JuliaHub · GitHub) listed as their first organization? Are all JuliaHubers also members of JuliaLang?
I’d want to see stats on merged PRs as well, and stats on issues, open or closed, would also provide useful information. Someone who ran into a bug in their work and reported it is still important even if they’re not the person who made the fix.
Is there a reason not to consider all organizations? Many Julia developers are members of multiple Julia-related organizations, and it would be strange to not count them. For example, you didn’t find any “JuliaHub devs”, but the language co-founders and many of the core developers are members of that Github organization. On the other hand, many of the bigger contributions to SciML packages would be labeled “JuliaLang” despite coming from members of the SciML organization.
I don’t know if it would help, but organizations do list their members under People, so that’s another place besides individual profiles to check membership.
EDIT: I tentatively suggest a split of this PR stat subtopic as it might have a life of its own.
If they are and the order was uniformly distributed then you’d see many of them as listed to belong to the JuliaHub org, right?
My only conclusion is that GitHub has some sort of preference of listing the JuliaLang org first, but I have no idea of why (order is definitely not alphabetic).
I hit the rate limit on the GitHub API, so I only obtained what was easily available to me :). A member of JuliaLang could access it freely and completely. For all other questions, the answer is actually almost the same.
I tried to parse orgs where I’m a member and I didn’t have any problems with them, so I can easily parse complete statistics for them. Possibly, my parsing script isn’t optimal for parsing large organizations. But I do not have time to play with sleep’s and try to find it out.
But I think we are quite diverged from the topic, so if you have any better proposals how to form this statictics you can do it.
The answer is just to create more materials. Quickest way is to get people to jump onto a podcast and then use the transcripts to generate blog posts. @bvdmitri@juliohm would you like to help coordinate that? I have some time in the next two weeks I can do some recordings and I know @mitiemannn has been wanting some help.
I haven’t been around long enough to form a strong opinion on any of the topics discussed. I just wanted to say, that for me as an ‘outsider’ the podcasts are super helpful to understand what’s going on. I also think the JuliaCon talks are a great resource and opportunity to explain to people what you are doing, and to be honest it’s more fun to watch those than reading a blog post. Like the talkon Pkg’s new SAT based solver, fascinating stuff. For me, those resources have been instrumental in showing where Julia is heading and I want to be a part of that.
Some sidenotes:
Python only created a steering council in 2018 with PEP 8016, so 24 years after version 1.0. I think we still got some years to go?
It is easy to extend and modify the internals of Julia, much more so than in Python thanks to the design of Julia enabling that out of the box. Which also means there is less need for a central organization to drive core changes to the language itself.