Modular has released Mojo 1.0’s compiler and toolchain as open source under Apache 2.0 with LLVM exceptions, ending the unusual split between a public standard library and a closed language implementation. The August 18 release puts the code required to build Mojo in Modular’s public repository. For developers evaluating the language, that is the difference between trying vendor-supplied binaries and being able to inspect, compile, modify, and fork the implementation itself.
Mojo is a general-purpose compiled language aimed at high-performance work across CPUs, GPUs, and AI accelerators. It reached 1.0 one week before the source release. The two milestones reinforce each other: 1.0 gives developers a stated compatibility baseline, while the open compiler makes that baseline independently inspectable. Neither guarantees a thriving ecosystem, but together they make Mojo a more credible long-term dependency.
The compiler is finally in the repository
Modular describes Mojo’s first four years as an open community built around a closed compiler. The company opened the standard library in 2024 and later published a large body of kernels and supporting code, but the component that parses, checks, and generates code for the language remained proprietary. That gap has now closed.
The main Modular repository contains the compiler, tooling, standard library, tests, and build files. Modular gives this path for cloning the project and running a Mojo program with a compiler built from source:
git clone https://github.com/modular/modular.git
cd modular
./bazelw run --config=build-mojo KGEN:mojo -- run hello.mojo
The repository uses a Bazel wrapper. According to Modular, the command downloads or builds the dependencies needed for the compiler and standard library, while --config=build-mojo tells the build system to use the local source. The published test command can also run the standard-library suite after compiler or library changes. A separate --config=prebuilt-mojo option uses a nightly compiler binary to save build time.
There is an important boundary here. Modular says a prebuilt compiler is still required when customizing MAX kernels or models. The Mojo compiler can now be built from source, but that does not mean every part of the broader Modular stack has the same status.
Why the implementation matters
A compiler is more than packaging around a language. It decides how source code becomes machine code, how types and ownership rules are enforced, what diagnostics developers see, and how programs target different hardware. When only binaries are available, users can test those decisions but cannot fully trace or alter them. Publishing the compiler makes code generation, optimizations, diagnostics, and platform support available for technical scrutiny.
That creates several practical options. Researchers can study the implementation rather than infer it from output. Teams can carry patches for a required target, audit behavior that affects production code, or maintain a fork if upstream priorities diverge. Hardware vendors can examine where a backend or runtime integration would fit. None of this means those efforts will be easy, only that the legal and technical door is now open.
The repository license is Apache 2.0 with LLVM exceptions. That is a permissive basis for using, modifying, and distributing the code, while the LLVM exceptions address how compiler-produced binaries are treated. For companies considering Mojo in commercial products, the choice is materially less restrictive than a source-viewing arrangement.
The release also arrives with an existing contributor base. In its Mojo 1.0 announcement, Modular said nearly 200 contributors had landed more than 1,100 pull requests to the open standard library, changing over 200,000 lines. Those are company-reported figures, but they show that the compiler is entering a repository with an established public workflow rather than starting as an empty code dump.
Open code does not yet mean open governance
The immediate contribution model is more limited than the license. Modular says it is not ready to accept contributions to the compiler and tooling, although it aims to do so by the end of 2026. Developers can read, build, modify, and fork the code today, but they cannot yet expect a compiler patch to be reviewed and merged upstream.
That distinction matters because open source has two layers: permission and participation. Apache 2.0 supplies durable permission. Participation depends on issue handling, design discussions, review capacity, release engineering, and who has authority to merge changes. Mojo has taken the larger legal step, while its compiler governance is still controlled inside the company.
The corporate context sharpens that question. Qualcomm completed its acquisition of Modular on July 29. The announcement said Mojo, MAX, and Modular Cloud would continue as products and brands, and that Modular’s open-ecosystem mission would continue. Releasing the compiler weeks later is concrete evidence for that commitment. It does not, by itself, establish a community-led roadmap or neutral foundation.
Corporate ownership does not weaken the license already attached to released code. It does shape staffing, priorities, trademarks, release cadence, and upstream decision-making. The useful test will be whether outside developers gain a predictable route from bug report or design proposal to an accepted compiler change.
Mojo is open source; MAX is not
Modular bundled the Mojo news into a broader set of ModCon announcements, so the labels need care. The company’s conference summary says Mojo 1.0 is fully open source. It separately says the MAX license has dropped device-usage restrictions and that MAX will become source-available alongside an industry alliance program. Source-available is not the same as open source, and it would be inaccurate to apply Mojo’s Apache status to the whole platform.
The same announcement says native Windows support for Mojo is coming through work with Microsoft’s Windows team. Mojo currently supports macOS and Linux, with Windows use available through WSL. No delivery date was given for the native port. This is exactly the sort of work an open compiler may eventually make easier to inspect and extend, but for now the Windows effort remains a future commitment.
Modular also presents Mojo as a route to portable high-performance software across varied processors and accelerators. Opening the compiler makes that proposition testable in a way a closed binary cannot: outside teams can examine backends, reproduce builds, compare generated code, and attempt new targets. It still does not prove that one program will perform well across every advertised device. Independent ports and benchmarks now matter more than launch-day claims.
Version 1.0 is a baseline, not a finish line
Mojo 1.0 is primarily a source-stability promise. Modular says changes during the 1.x series should be mostly additive and that necessary breaking changes will be managed more carefully. That offers developers a clearer maintenance expectation after a period of rapid language changes.
The roadmap is not complete, however. Modular lists a robust asynchronous programming model, pattern matching, and unions among the capabilities still ahead. Tooling reliability, package availability, debugging, build times, interoperability, and real-world performance will also influence adoption at least as much as access to the compiler. A version number and a license remove major uncertainties; they do not remove the ordinary work required to make a language dependable.
What to watch next is concrete: whether independent developers can reproduce source builds across supported systems, when compiler pull requests begin to be accepted, how public design decisions become, and whether the promised native Windows support ships. Third-party ports and sustained production use will show whether Mojo’s newly open implementation becomes a shared project or remains primarily a vendor-developed language with public source.