What happens if Julia Computing goes away?

So, I’m mostly a private Julia user. I like it very much, and I try to contribute to the community with docs and code, but I’m not really in a situation to purchase anything from Julia Computing. I had a candid conversation with someone familiar with the matter at JuliaCon and got the impression Julia Computing’s financial situation was, well, tenuous. The quote was “It’s hard to get people to pay for a compiler”. On the other hand, I also had the impression Julia Computing was still operating under its own steam and making ends meet. I’m not vouching for either statement–just impressions I got from the conversation.

In any case, what I took away from the conversation is that Julia Computing is doing alright at the moment, but the business models is tricky. I’m sure Julia will go on with or without Julia Computing (which isn’t to diminish all the amazing work it’s behind), but I’m wondering what the Julia landscape would look like without the company. I’m wishing for you to succeed, of course!


maybe right now is the only one, but in the future i see perfectly factible the existence of more than one businesses with the same service that Julia Computing is offering (consulting and professional support in Julia). The main advantage of Julia Computing is that the members of the organization are also the main developers of the language, but with time, other companies will jump to the bandwagon of proffessional support of julia, using code that may or may not be open source


Julia Computing isn’t going anywhere anytime soon, but that wasn’t the question of course, so for the sake of argument, let’s take a look at Julia Computing’s role in the ecosystem and what we’re trying to do to make this thing sustainable for the long term.

Julia Computing isn’t the only entity that’s making sure Julia is strong and stable (see blog post here: https://julialang.org/blog/2019/02/julia-entities). This was deliberately set up that way to make sure that the Julia project would be resilient no matter what happened to the company. That said, Julia Computing does pay for a fair amount Julia development, especially on the maintenance side (bug fixes, releases, infrastructure, etc.). The open source community is great for getting lots of crazy projects into the language, but it’s hard for somebody who isn’t paid a salary to consistently put in the time and attention required to keep all the plumbing running, respond to bug reports, etc. This is also not generally something we directly get paid for [1], so it’s mostly paid for with revenue from other sources (consulting, research grants for particular applications, etc.).

The worry here of course is that doing things this way isn’t necessarily sustainable. The maintenance cost of julia roughly scales with some function of the size of the code base, the number of users and the maturity of the project (changes become more complicated when you need to make sure not to break users), while the size of our consulting business mostly scales with how good we are at that (to some extent wider julia adoption may help the consulting business, but it’s mostly proportional to how many people are doing the consulting). The plan is to fix that by building paid products to help users that are using julia in business critical applications (the idea being that the number of such users would have roughly the same scaling behavior as the maintenance cost of julia). JuliaTeam (https://juliacomputing.com/products/juliateam, https://juliacomputing.com/blog/2019/02/13/JuliaTeam-Vision.html) is the first step in that direction and we’re expecting to be able to provide some value out of this development for the open source community as well (you may have seen the code search on pkg.julialang.org, which is served from a hosted, stripped-down version of JuliaTeam).

However, whatever happens, I don’t think Julia is going anywhere. As I mentioned, there’s several other organizations supporting julia development. Lots of companies and academic labs are now using julia and paying people to work on various things in the ecosystem. The julia project was around for 6 years before Julia Computing was founded. Julia isn’t a “corporate open source” project where some company happened to open source some code. Julia Computing exists, because the core people working on the language wanted a vehicle that lets us do that without too much distraction, and so I far I think that’s worked out pretty well. However, even without it, I’m fairly confident we’d find ways to do just that (we did for many years before the company was around after all).

[1] In the past we’ve gotten some grants from various foundations, which is very much appreciated, that have helped with the maintenance burden, but mostly it’s for feature development.


Well, we aren’t trying to get people to pay for a compiler, so the difficulty of that is fortunately not directly relevant.

In the sense that we’re an early-stage company perhaps, but I assure you a lot of planning and sweating over spreadsheets goes into this. We’re not exactly sitting around wondering when a check will bounce and we’ll all suddenly have to go home.


Most of us who’ve been around since ~2013 (or before) are in it for the long haul. If Julia Computing went away, I know my next move would be to figure out how to keep working on Julia (I can only speak for myself of course, but I’m pretty sure Stefan, Viral, and others would say the same). I believe there are many ways I could do that.


I think it’s safe to say that the JC devs provide so much value, and are such astonishingly talented people, that many of us would bend over backwards to provide havens for them if things went south.

That said, I’m instead expecting to cheer at the next doubling in size of Julia Computing. The growth has been amazing, and very gratifying to see. Congrats to those who pore over spreadsheets as well as those who write code—both sets of efforts are essential to the tremendous success so far.


In my opinion, this alone can be a case study for open source models in general.


It would be good to know the numbers, but it seems there are also an increasing number of us paid to work in julia for scientific organizations outside of Julia computing. Personally this gives me a strong incentive to make other parts the ecosystem functional around our projects - and in Julia it’s easier to extend this to working on Base than in really any other language.

This unreasonable amount of code sharing and contribution should also have some positive effect on Julias long term resiliance, which I think will only improve as the projects currently being developed become locked in as the core tools for organizations with real funding.

But the issue queue might not get so much attention… so its great that this wont happen anyway :slight_smile:


I think Julia Computing’s “tenuous” financial situation is vastly preferable to some of the alternatives.

Recently at my job I’ve had a number of encounters with Databricks, the company which is primarily responsible for developing Spark (which is Apache license open source, for those not aware), and I do not like the way that seems to work at all. Some of the things said in advertisement of Databricks almost sound like tongue-in-cheek statements that they actively sabotage Spark for the sake of forcing people to pay for Databricks. On top of that, I have a number of bad things to say about the Databricks software itself from recent experience, which include a lot of the usual complaints about proprietary software, which one would have hoped to avoid by simply using Spark.

The relationship between Spark and Databricks is so shady that I’d list it as a reason to avoid using Spark altogether.

I am glad that Julia seems at zero risk of being in this type of situation anywhere in the foreseeable future.


:100: Just the fact that they respond so openly to posts of this nature is immensely comforting.


I’m pretty sure I’m the person that Aaron was talking to and he seems to have misunderstood/misconstrued what I was saying. I definitely did not use the word “tenuous” with regard to Julia Computing’s financial situation—frankly, we have an very large runway for a startup. I was explaining that finding product market fit around an open source project is hard. Hence the comment that getting people to pay for compilers is not a viable product strategy in 2019 like it was once upon a time. I’m pretty convinced that we have finally nailed a good open source product strategy with our JuliaSure, JuliaTeam, JuliaRun lineup. Now the pressure is mostly about actually executing the fairly ambitious product vision.


If Julia Computing really needs money, Initial Coin Offering allows it to raise capital without losing the control of the company.

It is fairly easy to conduct an ICO nowadays. Considering Julia’s user base, I believe its ICO will be very fruitful.


It was actually someone more on the financial side of the company—but he didn’t say “tenuous,” either. That was just something I (perhaps incorrectly) inferred. Wouldn’t be the first time.

An any case, I appreciate everyone being so forthcoming about this topic. Especially @Keno’s response was really helpful.


If Julia Computing really needs money, Initial Coin Offering allows it to raise capital without losing the control of the company.

I am positive about much decentralizing tech, yet I think this would be a big distraction for Julia or Julia Computing. Even if an ICO is technically possible, it would also carry a taint of money-grubbing unsavory types and other bad associations. Even without these bad associations (true or not), the economics of a token offering are tough to get right; it’s not at all obvious how you’d go about that with Julia.

I guess there’s no chance that Julia or Julia Computing would seriously consider an ICO, so I’m preaching to the choir :slight_smile:


Wait a second, I thought ICO was just some thing they came up with for that Silcon Valley show to showcase the collective insanity of tech! I need to get out of the ivory tower more often…

Thank you for asking the question (even if the reality is likely that Julia Computing is simply at the same level of anxiety as any other small company). Worst case scenarios are important thought experiment to work through for those of us thinking about Julia in the longrun.

Considering the alternative example given of a shady companies purposefully neutering open-source software to upsell the commercial version, or (potentially well meaning, but without governance?) companies completely replacing an open-source language’s software with their own stack (i.e. RStudio and tidyverse), I think we have it pretty good.


An ICO implies there is something being tokenized, usually some type of utility. What might that be? Maintenance units? Compiler credits? There is no shortage of ICO backed projects with unrealistic business models in which unsuspecting speculators have purchased tokens based on shady tokenomic models.

On the other hand, if JC were to tokenize the company by selling shares via a Security Token Offering (STO) I’m sure they could make a case for the company’s business model, raise as much funding as they need, and provide additional liquidity for the current and future shareholders.

Frankly, I don’t think there were any models (in the sense economists or businesspeople understand the term) in the first place.

I don’t think there is any reason to believe that Julia Computing has a comparative advantage in experimental finance. I hope that they will be around and are successful in fulfilling their mission, as that would really enrich the Julia ecosystem. But this is more of a matter of having a viable business model (and, of course, luck) than tagging “blockchain” on some concept and hoping that people would give them money.


You are seeing the growing pains of many or most open source projects. Open source makes finding paychecks difficult. The Julia core contributors and founding contributors are singularly talented and visionary. Even they have difficulty obtaining reliable and sufficient paychecks if they are primarily working on the open source project. MIT hosted initial development of Julia and remains a strong supporter. But, even as the visionary work continues, much of the work to build the core language, its infrastructure, and supporting packages and tools focuses more and more on essential, ongoing engineering. An academic institution, even MIT, with its support for a variety of research institutes–many of which do lots of engineering work, wants its professors to do research, primarily, and teaching, secondarily, and not mostly day-in/day-out engineering.

Many of the most successful open source projects rely on contributions from for-profit entities and very well-funded not-for-profit entities. For-profit support comes in the form of direct cash contributions to support salaries (sometimes long term, but more often time-based) and in the form of permitting or even specifically designating employees to contribute to the open source project. For-profit entities built solely to support a single open source project have more challenges differentiating their for-profit activities and projects from their support for the open source project (or “community edition” as many call their products). The difficulty is real even when their contributions to the open source project entail LOTS of work, high quality work, and genuine intentions to support open source (e.g.–the problem is NOT bad intentions). The primary challenge is in creating some sort of extension to or application of the open source work that can be SOLD, while still providing many person-hours to the open source work.

It seems in my quick look at the scene that the most viable open source projects, in terms of gaining long term support from highly qualified contributors–some of whom are full-time–and who receive paychecks that enable them to support families (or other longterm life choices)–are projects that are supported by for-profit entities that have significant reliance on the open source project. They rely on the project; want it to be high quality with longterm support; and realize that they have no competitive issues even if other entities (for-profit companies, not-for-profits, educational institutions, hobbyists, government agencies, whoever…) benefit–with or without contributing. They see that other for-profit entities will also support the project with cash or employee contributed work (without concern over any competitive issues) and they don’t mind the “free-loaders” (many of whom also contribute some and provide viability for the work simply by using it).

Sometimes, the for-profit entities rely on the project because it is “free like beer.” More likely, they support it because the open source project might well become the best technical solution for their needs BECAUSE of the breadth of support it achieves. Sure, they are getting a bargain, but in quite a few cases, they make legitimate contributions of cash, code, and people’s time.

This may not seem the ideal form of support to some who sincerely endorse open source as a movement and alternative to for-profit licensed software. (I’ll avoid that topic…) Yet, it seems the strongest path, if not the only path, to long term viability. We have Apache HTTP Server, nginx, Python, various flavors of and extensions to javascript. I think Linux is a very special case as packaged distributions are not particularly viable for other kinds of projects than an OS. Wordpress is also a special case as Auttomatic is a very unique company that does make Wordpress open source, but has a very strong for-profit business model. Without making any comment at all on the merits of javascript either way, Node js gets lots of support from many for-profit entities and most of the various flavors, tools, and extensions remain available as pure open source.

This suggests that a good path (not the only path…) forward for Julia is:

  1. a governance body that is open and not-for-profit that provides long term technical guidance, (rare) dispute resolution, and market awareness. This may begin with Julia Stewards and might or might not evolve to a foundation. The foundation advantage is it provides some institutional stability that may survive turnover among the specific people. The foundation disadvantage is that it requires funding, etc, yada-yada.
  2. stronger adoption by for-profit entities as a tool that they depend on so that they commit to contribute employee time and cash to the project.

Perhaps Julia Computing can be one of those for-profit entities, though it is difficult for a compiler because it is hard to draw boundaries between the compiler and its open source package ecosystem and “stuff” one can charge money for. One possibility is to create a “Julia Studio” analogous to the absolutely brilliant R Studio, which was created by one of the great (formerly) closed source developers, JJ Allaire. I have to point out that R Studio is available as open source and its commercial version is a sort of GPL avoidance license (I think this is not a long term thing, especially for something like Julia which is already offered on a “permissive” license) and support. One could imagine some deep application focused packages built around a “Julia Studio”. The generic edition could be open source. The version for finance–hey, make those guys pay. A risk modeling edition could be for-pay. It might not be realistic for the existing Julia Computing to do these application-focused tools–but it could be the licensor of the core “studio” asset for commercial extensions, and receive a royalty for both the core asset and the use of the brand. Just an idea…

I still believe that #2 above is the most likely model with support from a wide variety of for-profit entities who need an awesome tool for statistics, analytics/exploratory data analysis (freedom from Tableau?), machine learning, data munging, modeling, etc. Some of these companies might be in the tools and data business themselves, many more would be “users” and glad for the freedom of a broad ecosystem of great tools (e.g., not as motivated by “free like beer”). They already pay for SAS and stuff from SAP (with some regrets), etc–but they want the tools and products to be more open to specialized extensions they need–and they want to benefit from the array of improvements that many researchers contribute to the core tools.

We clearly see more academic support for Julia at a variety of universities. It seems that there are more commercial users. The progress of the compiler is excellent. The expansion of the package ecosystem is strong. Julia certainly seems viable. Still, a stronger base of support seems necessary for the language and its ecosystem; to provide some respite for the founders and core contributors who have done such excellent work; and to provide support for a new and expanding generation of contributors.


Something that I imagine could be viable is that whoever is willing to pay for something gets

  1. a say in development priorities (ie they are donating for support of a new feature),
  2. extra support while the feature is experimental and being hammered out.

Just as an example, imagine that faster compile times or better compiler support for some kind of code is important to someone. So they ask Julia Computing to contribute to this, then they know they can start using it right away before the next release (at least experimentally) since they get support with fast turnaround times.

I believe this essentially exists already: offer enough money and Julia Computing will implement a requested feature in Julia (within reason). Just contact them and they’ll provide a quote.