Item — HN Reader

They do very much plan to open source Mojo.

From Chris Lattner when asked about the date that will happen:

I would tell you if I knew . Our priority is to build the "right thing" not build a demo and get stuck with the wrong thing. My wild guess is that the language will be very usable for a lot of things in 18 months, but don't hold me to that.

It WILL be open-sourced, because Modular on its own isn't big enough to build the whole ecosystem.

4 comments

Hard needle to thread. I understand the risk of getting community momentum in a direction you don't want to go, but I'm also doubtful that much of the audience they want is interested in a closed source programming language. Hoping they can thread it because I think it's a good idea and Swift is pretty nice.

I think they're just playing a larger distribution game to get people locked into Mojo then eventually pay for their Modular engine hosting services, just about the same as most open core, VC backed startups.

I see what you're saying, but it's pretty different from an open core analytics product or something. This is a language/dev environment and the bar is a lot higher because 1) I know it's going to be a big investment to learn the language and ecosystem 2) I'm deeply locked-in technically by writing my stuff in this language 3) the competitors are open source and at this point I'm not worried about python, numpy, typescript etc going away. My feedback is basically that despite this project looking cool, I will not be writing any Mojo until it's open source.

> They do very much plan to open source Mojo.

They do very much claim to plan. There's a bit of difference.

Chris has a pretty solid reputation. I doubt he’d throw that away.

Sometimes it’s okay to trust people in this space. To me, this is one of those times.

What if it’s less his choice and more about convincing investors that it makes sense?

That shouldn’t be hard I think. My confident guess is that there will be multiple backends for the language, an open source bare bones one, and one which integrates with their “value add“ highly scalable backend, with optimization for distributing work across GPU farms or even custom hardware.

They should just open source it now, but closed to contributions (no PR).

That’s how SQLite operates and it works well.

Not a bad idea at all.

So, it's basically the same approach they took with Swift. It makes sense.

It doesn’t. Free software is an ideology, not a license. You can’t be said to believe in software freedoms if you release nonfree software.

An analogy would be that you don’t believe in human rights if only 10% of your business operations violate them.

Software freedoms are important. Don’t release proprietary software. Doing so is bad and makes the world worse.

It's hard to fund development without releasing something, and at the same time, releasing it prematurely runs the risk of entrenching undesirable features/behaviors/etc that stifle development of something better.

Releasing it closed source allows them to point to something that justifies further fund raising and allowing them to control the direction of development while getting user feedback.

This isn't some esoteric language where if mojo vanished you'd lose your whole project and have to rewrite it into something else. It's python with some syntax sprinkled on top, so vendor lockin isn't a huge concern.

They didn't open source Swift out of the gate because they wanted to guide its development according to the features and plans they had for the language. Wanting to have a firm grasp of the language's core features and implementation is reasonable. After all, I believe Lattner was unhappy with some early directions they took with Swift, but it was too late to change anything because libraries and such had already been written. I may be fuzzy on that, but that's what I seem to recall.

Also, I am not an absolutist where free software is concerned. It doesn't make the world worse to release proprietary software. Especially if you have the stated goal of eventually open sourcing it.