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:
- 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.
- 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.
