I am surprised that you consider VS Code an example of transparency. It is not even FOSS, but part proprietary.
I don’t know what is this FOSS project to be completely honest. I can read about it. To add to your point, you can be very transparent about the fact that something is proprietary or commercial, and that you don’t care about others’ opinions — that’s still a form of transparency. That is what, for example, Mojo does. They are very clear and transparent about their goals being a commercial product and they most likely will first evaluate their business goals, community is the second (btw they also do have a roadmap)
I assume the transparency issues you’re referring to in the context of VS Code relate to its distribution model and Microsoft’s specific license terms. But that’s not quite the same as transparency in the development process itself. Nevertheless, I understand your point and VS Code might not be the best example. I checked their roadmap, goals and direction. I do think the way they structure their goals, ideas, roadmap and how they communicate general direction is something that Julia community can learn from, even though its not ultimately FOSS
P.S. BTW I cannot find Julia on this FOSS website. Actually also cannot find Python. Rust is there.
Beat me to posting the Mojo roadmap, which I thought was pretty well structured in terms of showing where they are thinking about going, how that aligns with their core vision, while also refraining from promises about timelines. Chris Lattner also gave a talk on it recently.
I think comparing Mojo to Julia is not useful. Firstly, it is very easy to make a roadmap that early on in a project because you are lacking so many basic things that are obviously needed. I mean, look at this:
Basic constructs : Functions, structs, control flow (
if,for, etc.).
Sure, in the early days of Julia, it wouldn’t be hard to have a road map:
- Have a package manager
- Enable FFI
- Have threading
etc, but Julia is at a way higher level of maturity than that.
Secondly, the things on that roadmap are quite nonspecific. Julia could put:
- Improve AOT compilation and the deployment of julia projects on other machines
but it doesn’t really mean anything, and you can’t make any real choices or decisions based on it.
Thirdly, Mojo is (more or less) a completely VC-driven project. This road map they have there is partly for users and partly for investors. It’s basically an infomercial. Julia has no real need for that.
Finally, Mojo said for the longest time that the language would be syntax and implementation compatible with Python. At least I was scratching my head about that because I saw they basically had PyCall.jl in there, but that was it, and it felt pretty much impossible to make a new language be fast and plug-in compatible with Python. And then they of course scrapped that and said the support for Python would indeed be via the same mechanism as PyCall.jl. So why would I put much belief in the current roadmap? Fool me once, etc. Which is another problem with road maps, unless you are careful, you erode the trust in future things you say.
At its core, the Julia project is just people. Hundreds of people. Julia isn’t heading anywhere by itself, it’s being pushed and prodded along by lots of individuals with lots of varying motivations and bandwidths and priorities.
Julia is not a company, though many contributors work for companies and some find ways to contribute as part of their paid work. It’s not a product of a company, though many companies build products atop it. It’s not a charity, though it has some limited support as a NumFOCUS project. It’s not academic, though many contributors work in academia and some find ways to fund their work. It’s not a dictatorship, not even a benevolent one, though high regard is granted to the founding four and other senior members of the project. It’s not a democracy, though respect for all is a foundational principle of our community.
The model I like the best here is Rust’s because it focuses the people. Even the goals themselves are explicitly compiled by people: the goals team. It didn’t magically manifest itself, someone did work to make it happen:
This is a really good blog post, as is the referenced Rust is not a company (which I only found after writing the same words myself), with the caveat that the Rust project is larger than Julia.
To be fair, even the best roadmaps aren’t guarantees and even the best plans can be scrapped up to a point; that’s something emphasized by several commenters including myself. Mojo also eventually got something right by putting some Python fundamentals (classes, inheritance, untyped variables) into the “NOT STARTED” Phase 3 behind their actual priorities. Initially they just had the much vaguer “Mojo will also support Python-style classes in the future” and implied they’re much more motivated for a Python superset, no checklist.
I think the meaning of transparency here is that even developers of wholly proprietary software can communicate what big things are being worked on (though how well it’s going would be more opinionated and uncertain at best). Licensing is a separate and important issue to consider for dependencies.
Hey Guys,
What are you talking about?
Thirdly, Mojo is (more or less) a completely VC-driven project. This road map they have there is partly for users and partly for investors. It’s basically an infomercial. Julia has no real need for that.
Isn’t JuliaHub venture capital backed? I just took a look at the website and saw that at least three venture capital funds have representatives on the Board of Directors. To be clear, I have nothing against venture capital funds. I actually like them. However, I think it’s desirable to be ethical and transparent, especially in a public setting
At its core, the Julia project is just people. Hundreds of people. Julia isn’t heading anywhere by itself, it’s being pushed and prodded along by lots of individuals with lots of varying motivations and bandwidths and priorities.
Who are you representing here, if I may ask? To be honest with you, the structure, as I currently understand it, is a bit mind‑bending, to say it mildly, especially since the whole project is advertised as a scientific undertaking.
However, I might be very wrong, my understanding is based solely on publicly available information.
To sum up, let me add a smile. :- )
Yes, but you need to elaborate on what your point is because I do not see it.
Purely for myself, as someone who cares deeply about this project and the community.
Yes I am employed by JuliaHub, but my time here is a distraction from what I should be doing for work. I have a commit bit to the Julia repo itself, but I use it less than I feel like I should. I’m a moderator and administrator of the discourse board. I’m not speaking on behalf of JuliaHub, nor am I speaking a committer, nor am I speaking as a moderator. I’m speaking for myself, and doing so primarily to describe my own understanding.
You can read all about JuliaHub’s corporate mission on the corporate site. I’m very proud of the work JuliaHub does, but I tend to be fairly restrained about it in these discussions because JuliaHub’s mission isn’t about amassing a large userbase or developing Julia for the sake of developing Julia.
Yes, Julia was launched out of an academic lab, and I (and many here) care deeply about science.
Sorry, I don’t see your point either, which is why I asked about the paragraph you wrote. Anyway, the discussion is long and covers many topics, so it’s easy to get lost.
So do I.
I think you are confusing Julia with JuliaHub. The former is an open source software project, the latter is a company. They are not the same thing, nor does JuliaHub own or control Julia.
I get the impression that Niko created that model to address the burnout problem that the Rust project suffered from until very recently.
What I like most about the model is the six-month timeframe. Although most goals require more than six months, you can see the progress of each one, and some even show no progress at all.
I hope the updates posted on Julia-lang blog are shorter than those on Rust blog.
Just offering it as an example of a roadmap; I was pretty clear in saying I thought the structure was something that could inform the present discussion. Don’t believe I said anything about either Julia vs Mojo (the languages) or the actual content of the Mojo roadmap… all your points are valid in that context, but the discussion is about “lack of clarity, long-term direction and governance” – it should be acceptable to change your direction for considered reasons; the world of computing continues to evolve.
No, not in the same sense as Modular, but as has been argued in this thread, there is something of a PR shortfall that has limited adoption. Many of us not working in companies built around Julia may have a slightly different perspective on this that has, in part, motivated this discussion.
To remix some statements that various people have made, I would argue that precisely because of the above, and because the project is more mature, and it is not obvious where it could go next, having more structure to this process could enable bigger strides to be taken, more people being able to participate, or at least understand the big picture of these activities.
@DNF I don’t think so. I mean, I don’t think I’m confusing those topics. However, this is an asset class that in nature is private and I have not done any in depth research on this topic (it is not my business). As for the sentence you’re referring to, it is part of my reply to @kristoffer.carlsson’s post (paragraph). In general, I joined this discussion because at some point my understanding was that the discussion was about a post venture capital governance model for Julia and about some general comments on its long term direction. I now see that my understanding was wrong, as the majority of topics covered here are quite different. With all due respect, I’m no longer interested in discussing or participating in this particular thread. I use Julia for a few projects I’m working on and I enjoy computers in general, and I’d be happy to connect on other topics of common interest in the other threads.
I think comparing Mojo to Julia is not useful.
I’m fine dropping Mojo as an example and only have as an example other open source languages like Python or Rust.
Julia has no real need for that.
Disagree, Julia has a real need for that.
Disagree, Julia has a real need for that.
You probably misunderstood. With “that” I meant for an infomercial-style road map whose main purpose is to hype up the language and make bold promises for the future.
At its core, the Julia project is just people. Hundreds of people. Julia isn’t heading anywhere by itself, it’s being pushed and prodded along by lots of individuals with lots of varying motivations and bandwidths and priorities.
I’ll repeat myself here — Julia is not unique in this regard. The Python project is also made up of people — thousands of them — each with their own motivations, priorities, and levels of involvement. Yet they do have a better organization in my opinion.
it’s being pushed
The question I had in the beginning of this thread where is Julia currently being pushed by all these individuals? There is clearly some direction. But it’s often hard to tell without digging through countless (and sometimes outdated) discussions and issues. The goal of this discussion should be is to learn from other open-source communities, which operate in a similar way, and see how we can organize Julia’s direction more effectively. Doing so would benefit both users and developers alike.
When I moved to Julia from Matlab I was well aware that, unlike Matlab which has one company making decisions, or C/Fortran/C++ which have international standards committees, Julia (like all other open source things) is the product of a collective of volunteers. I had to think a bit about this and whether is was the right thing for my project. I understood the risks (use a package with a bus index of 1 or 0, find that the thing you need has moved down on the priority list, ask for help and get RTFM …) and tried the language/culture/ecosystem out and was happy. The culture part may be what the OP is most worried about.
The OP may not be happy and the OP’s management may want something only an international standards committee can provide.