Julia's business model

StefanKarpinski · November 5, 2021, 1:43pm

Yes, I did because someone DMed me that MathWorks does allow downloads of old versions of Matlab, so I edited it to change the incorrect claim.

cormullion · November 5, 2021, 2:11pm

I wonder whether that old license file works, though.

I have a fair few Mathematica notebooks created in versions 7, 8, and 9 that are sitting on my hard drive waiting for me to buy a new license so that I can open them again. Fortunately nothing of value, in my case.

lobingera · November 5, 2021, 2:28pm

I’m using matlab (at work) with a network license and sometimes run old versions (2015 etc.) of matlabs on VMs (getting old OS/linux versions is actually more tricky than matlab itself) and this just works.

bilderbuchi · November 6, 2021, 10:53am

Is it, though? I think the concerns around “Julia+” have been discussed enough already, but what if he actually meant something else?

What happens when (not if) JuliaComputing’s venture capital investors expect to receive a big(ger, if not necessarily unicorn-level) return on their substantial investment?
One monetisation pathway could be to start pushing more and more useful/important features into JuliaComputing’s proprietary/cloud offerings (i.e., external to the Julia itself), maybe somewhat like Mathworks’ Matlab Toolboxes [1].

JuliaComputing rightly prides itself of having all creators of the language as their founders (as opposed to, say, Anaconda Inc. for Python), so they can control a lot of Julia mindshare and development direction. I think this makes it less likely that useful but proprietary features get an alternative open implementation by the motivated community.

That way, the language keeps all the openness features emphasized above, and people are not required to “pay for using the Julia language”, but the Julia ecosystem can still be nicely leveraged into ROI.

[1] possibly we’re already seeing the beginnings of this, as judging from remarks I’ve seen/heard, a standard component library for MTK seems to be destined to end up as a JuliaComputing offering instead of open-source, like e.g. Modelica’s MSL.

fwiw, I hope I’m wrong and just too jaded by seeing how VC influence plays out!

StefanKarpinski · November 6, 2021, 3:15pm

How is this different from Guido van Rossum working at Google, Dropbox and now Microsoft? Or Go being de facto controlled by Google? Or Swift by Apple? Or Rust by Mozilla? Everyone gets paid somehow. Do you trust megacorps more for some reason? I doubt it. Instead, I suspect it’s because you trust the individuals in charge of those projects to not be unduly influenced, regardless of their employer.

baggepinnen · November 6, 2021, 6:14pm

github.com

SciML/ModelingToolkitStandardLibrary.jl/blob/main/LICENSE

MIT License

Copyright (c) 2021 Julia Computing

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE

This file has been truncated. show original

Looks open source to me

jzr · November 6, 2021, 7:33pm

Everybody wants Julia to be successful and for its developers to be successful, and I’m sure the JC team are well-intended and capable technologists. But for me, my concerns are mainly not a matter of trusting those individuals. When investing in a foundational technology, I don’t want to rely on a single company. Incentives stemming from Julia Computing’s $28.6M investor obligations are only a small part of the risk—any single company would have some incentive structure that is not perfectly aligned with the broader community’s.

It is useful to consider two kinds of projects: those that are principally controlled by a single company, and those with distributed control.

Python is managed by the Python Steering Council, chosen by election from the core developers, and the nonprofit Python Software Foundation (PSF). It has been led by a distributed group of core contributors including van Rossum for a long time. “Python” and “PyCon” are trademarks of the PSF.

PostgreSQL has an “unwritten rule that the Postgres core team should not have over half of its members from a single company” and quickly expanded the Core Team after an acquisition merged large employers in order to resolve the issue.

Rust Core Team member Steve Klabnik wrote recently in a thread beginning “I refuse to let Amazon define Rust”:

In the beginning, Rust did have one sole patron: Mozilla. Everyone was uncomfortable with that arrangement, including Mozilla.

We spent years trying to get away from this situation. It had tons of negative effects.

Go and Swift each are essentially controlled by a single company. The company’s incentives drive the direction of the language and its ecosystem. Swift is regarded as an excellent language but has little adoption outside Apple-product developers.

Looking at Julia’s GitHub contributors of the last two years, I count 6 of the top 10 are employees of Julia Computing. The ecosystem packages are also largely supported by Julia Computing. The “Julia” name and logo are owned by Julia Computing and Stefan, respectively. In 2017, there was discussion about transferring the IP to a foundation but I haven’t seen movement on that. On the other hand, the JuliaCon proceedings committee isn’t a Julia Computing team.

I know Julia Computing’s contributions to the language and its ecosystem are massive, and the largest contributors perhaps unavoidably have the largest influence on the language. I don’t know in what ways the concentration of control and funding risk harming the language ecosystem as a whole, or how these risks can be avoided. But it’s worth looking for ways to mitigate such problems before they arise. I hope these discussions continue until that risk fades away.

johnmyleswhite · November 6, 2021, 7:48pm

I think if people are worried that too many of the Julia contributors work at Julia Computing, it’s worth thinking through the universe of potential fixes:

You remove some of the current Julia Computing people from the main contributor group.
You add more non-Julia Computing people to the main contributor group.

I’d even say that the single best group of people to provide the staffing for (2) are the people worried about the current setup since they have a clear incentive to fix something that matters to them.

jzr · November 6, 2021, 8:32pm

The remedies to concentration may include other options – for example, one not listed was “remove some Julia contributors from Julia Computing” (joke).

Part of the motivation for my comment is to suggest that this is an issue that affects the community as a whole. Julia Computing employees themselves, having so much at stake in the future of the language, might be well placed to work on solutions, as did major-contributor employees in some of my examples.

There are other ways of diffusing influence, such as defining a Core Team of decision-makers who might influence the direction of the language; funding a foundation to choose and provide development grants to independent developers, and so on. I encourage people to think broadly about how the language community can ensure its user base is represented in its contributor base and leadership.

jling · November 6, 2021, 8:54pm

this is vacuous, in the end, language design/direction is a technical challenge, it’s about who has the ability and does what. On one extreme, let’s say outside of JuliaComputing there are only novice users (this is not the reality btw, many top contributors are not JC), do you expect if somehow the community elect some “users” to a committee will solve the issue, if these users don’t know the details?

In the end the only “solution” (I don’t even see a problem tbh, it’s just a reality that is common in numerous FOSS projects’ life cycle)

and you can be assured that this will happen if Julia becomes successful, after all, if Julia doesn’t get used by enough people, the world couldn’t care less what we do with “yet another programming language”. This process takes time but I really don’t see there’s any “problem”, if you go back to 2014 would you say Julia was in a horrible condition because basically all top contributors are JC?

bilderbuchi · November 6, 2021, 9:24pm

Thanks, I was not aware of this yet (only “announcements” to expect, or pointers toward JuliaSim)! Happy about this brand-new development (and to be proven wrong), it makes MTK’s case much stronger imo!

lmiq · November 6, 2021, 10:03pm

As of today, one great incentive to youngsters contributing to the core Julia is the possibility of becoming a JC employee, which is probably one of the coolest places to work in computer science now.

One curiosity is how this mechanism of 1) new independent contributors appearing 2) they being incorporated to JC is taking place. Is that common?

oxinabox · November 9, 2021, 3:18pm

I think it might actually be more common for new significant contributors to the language to end up at the Julia Lab at MIT (as PhD students or RSEs) than to end up at Julia Computing.
Though I am aware of both happening in the last 6 months.

GregVernon · November 10, 2021, 6:38am

So quick question then – we’ve considered at some point possibly rewriting our commercial products in Julia (currently C/C++). Are you saying that if we write our software in Julia we need to MIT license it, i.e. distribute our software and source-code for free? That doesn’t seem very liberal and permissive?

rashid · November 10, 2021, 7:02am

That is not true as mentioned earlier:

You can read more about the MIT license here. The only requirement to follow when redistributing a copy and/or modification is to include:

The original copyright notice

A copy of the license itself

gustaphe · November 10, 2021, 7:07am

I think the important thing here, which is honestly a bit vague in the formulation of the license, is that you (afaict) must only provide the notice in relation to the redistributed code. So you can license your code however you want, but the part of your program that is redistributed must be accompanied by its original license. But you can say “Files a, b and c are part of Julia and covered by the MIT license:”

Keno · November 10, 2021, 7:10am

No

GregVernon · November 10, 2021, 7:12am

Ah, that makes a bit more sense – you’re right that (if you’re correct) is a subtlety-stated point. Glad to know the MIT license doesn’t “invade” the rest of a codebase.

DNF · November 10, 2021, 8:01am

So, that discussion was somewhat beside the question you were asking. There was never any disagreement about whether you can choose what license you want on your own code. The discussion was about whether someone could fork and release the code of Julia, the language itself, with the compiler and everything, under a different license.

The freedom to license your own Julia code how you like was never in dispute.

GregVernon · November 10, 2021, 6:50pm

Right, that’s what I thought we were talking about, but then reading this:

“Something” – could be anything
“Substantial portion” – if +90% of our codebase was written in Julia and we redistribute Julia for API purposes, that would probably qualify as substantial.

It wouldn’t have thrown me off as much if it hadn’t come from a co-founder / co-creator of Julia.