Tim made a great point about the strength of the Mojo brand. MAX on the other hand does not seem strong to me. The idea of combining them makes sense but it would seem like a stronger move to have Mojo as the thing users download and use, and MAX is just a library of that. With a commercial license if needed.
So much this. I have no problem with them making their managed cloud stuff source-available, but Mojo itself has to be fully open-source under an OSI license before I invest any time or effort into using it. No start-up intends to rug pull, but if they start running out of money.. And, for the case of them closing down, we need to have the Mojo language tooling be open-source and with a sufficient built-up contributor pool to maintain a community fork. It's no good saying "we'll do this in future" or "we'll do it if it comes to that" because it doesn't guarantee that whoever comes out the other side owning the IP will follow through.
pixi uses uv. poetry's problem is that is really only good for pure python projects. With pixi, you can add system library dependencies or other programming languages like rust or C++, like if you want to build out a pyo3 wrapper around a rust crate. They mention pixi is like git, but I see it more like docker, without needing containers.
Friends i am an application backend developer I want contribute to mojo which more system developing how to shift from application development to system developer only for mojo because I love its idea simplicity of python but more efficient and powerful so I want to help this movement I don’t know what to do
When will it really be open source ? The excuse of gradual open sourcing sounds like a scam and you are free to keep things closed an commercial, but don’t try to mislead us, I’m completely uninterested in the project if it’s not fully open source, this half assed positioning is purposeful misleading.
mojo/max is very young. Just a bit over a year since they first announced it. In contrast, rust was developed in-house for at least 3 years at Mozilla before going open source. And I believe Graydon was working on it over a year before he even released it within Mozilla. I for one think Modular talked about mojo too early, precisely because people now have this expectation that you have. I worked at Red Hat on Openstack, and I saw what happens when you have too many cooks in the kitchen. I'd rather they get feedback first, but still control the process in-house to have it more fully baked until fully open sourcing it.
The "we're not geared up to accept community contributions to the core language tooling, so we'll open source it down the road" reasoning seemed iffy from the start, but I was giving them the benefit of the doubt - it does indeed make little sense to expend effort to onboard compiler engineers at an early stage and the (unstated) idea they wanted to get a head-start in semi-stealth mode made sense. I was happy to wait until the open source release happened, providing guarantees that the language itself will outlive the next funding round, to jump in. At this point, I'm ready to give up on waiting. They've had plenty of opportunity to release the core while keeping the cloud platform value-add that they intend to monetise proprietary or source-available under something like the BSL. And they haven't. It's 2024: people won't accept developing on top of a proprietary language, especially from a start-up. .NET Core went open-source some time ago. CFML has been EOL'ed because no one cares. There is literally no single proprietary dev platform with any sort of adoption or mindshare. Time for a reality check and some action, or at least a clearly communicated plan of action (eg "we're going to be preparing for an open source release of the core language under X license over the next Y months"). They're also neutering the potential of a community ecosystem that makes languages successful by dragging their feet. This is a massive misstep strategically.
Tim made a great point about the strength of the Mojo brand. MAX on the other hand does not seem strong to me. The idea of combining them makes sense but it would seem like a stronger move to have Mojo as the thing users download and use, and MAX is just a library of that. With a commercial license if needed.
agree
Strong agree
Opensourcing mojo's compiler would help a lot
So much this. I have no problem with them making their managed cloud stuff source-available, but Mojo itself has to be fully open-source under an OSI license before I invest any time or effort into using it. No start-up intends to rug pull, but if they start running out of money.. And, for the case of them closing down, we need to have the Mojo language tooling be open-source and with a sufficient built-up contributor pool to maintain a community fork. It's no good saying "we'll do this in future" or "we'll do it if it comes to that" because it doesn't guarantee that whoever comes out the other side owning the IP will follow through.
Interesting to choose Pixi over tools like Poetry or uv
pixi uses uv. poetry's problem is that is really only good for pure python projects. With pixi, you can add system library dependencies or other programming languages like rust or C++, like if you want to build out a pyo3 wrapper around a rust crate. They mention pixi is like git, but I see it more like docker, without needing containers.
You do a great job. Thank you guys!
Big props on the thoughtful, up-front licensing discussion. ❤
Yay !!! ❤
OpenMI - "Don't be google" ;-)
Friends i am an application backend developer I want contribute to mojo which more system developing how to shift from application development to system developer only for mojo because I love its idea simplicity of python but more efficient and powerful so I want to help this movement I don’t know what to do
imagine that no one can download mojo we need a tutorial on how to download it !!!
When will it really be open source ? The excuse of gradual open sourcing sounds like a scam and you are free to keep things closed an commercial, but don’t try to mislead us, I’m completely uninterested in the project if it’s not fully open source, this half assed positioning is purposeful misleading.
mojo/max is very young. Just a bit over a year since they first announced it. In contrast, rust was developed in-house for at least 3 years at Mozilla before going open source. And I believe Graydon was working on it over a year before he even released it within Mozilla. I for one think Modular talked about mojo too early, precisely because people now have this expectation that you have. I worked at Red Hat on Openstack, and I saw what happens when you have too many cooks in the kitchen. I'd rather they get feedback first, but still control the process in-house to have it more fully baked until fully open sourcing it.
The "we're not geared up to accept community contributions to the core language tooling, so we'll open source it down the road" reasoning seemed iffy from the start, but I was giving them the benefit of the doubt - it does indeed make little sense to expend effort to onboard compiler engineers at an early stage and the (unstated) idea they wanted to get a head-start in semi-stealth mode made sense. I was happy to wait until the open source release happened, providing guarantees that the language itself will outlive the next funding round, to jump in. At this point, I'm ready to give up on waiting. They've had plenty of opportunity to release the core while keeping the cloud platform value-add that they intend to monetise proprietary or source-available under something like the BSL. And they haven't.
It's 2024: people won't accept developing on top of a proprietary language, especially from a start-up. .NET Core went open-source some time ago. CFML has been EOL'ed because no one cares. There is literally no single proprietary dev platform with any sort of adoption or mindshare. Time for a reality check and some action, or at least a clearly communicated plan of action (eg "we're going to be preparing for an open source release of the core language under X license over the next Y months"). They're also neutering the potential of a community ecosystem that makes languages successful by dragging their feet. This is a massive misstep strategically.