And another promising new tech goes down the kermit. Shame. And writing a book with the chap from infosys? Yikes, given what we have seen from the warm bodies drafted in as so-called developers from infosys, that cannot be a good sell for the book.
Glad with stuck with the python numerical stack now - far more mature.
I honestly do not get the controversy. They work as consultants to fund development and the start-up has been publicly known for almost a year. How is this any different from companies hiring developers to contribute to the Linux kernel or Google hiring van Rossum back in the day? The language is still free, as in freedom. Am I missing something?
I don't see what is the problem. They are selling training on Julia and Julia development. They are doing a great work on Julia, please let them monetize it.
Also, I wouldn't call it a startup, it's more a consulting company.
I think there are two possible concerns: 1.) The interest of their clients and the larger community may not align or even directly contradict each other. For example, it has been argued that the consulting work of the OpenSSL developers has been detrimental to the quality of the software and that it may have been one factor leading to the recent security problems. 2.) The Julia developers may at some point decide not to publish future additions to Julia under an open source license. Instead they may decide to sell an "enterprise" version of Julia. I don't know how likely these things are but there is certainly plenty of precedent in the open source world showing that it's possible.
I'd say that the actual news is that the Julia founders have found a way to make a living through consulting, enabling them to keep working on an free (in both senses) software. They've also managed to scale to bring on some large contributors too, which is even better. There are three choices, as I see it:
- They would have had to go work for another company that doesn't care about Julia. Its now a free time project.
- They would have had to go work for another company that does care about Julia. They get to work a bit on Julia, but focus shifts to what this company cares about.
- They work for themselves.
Not quite sure why this isn't a more common situation for open-source, it seems like the ideal situation for everyone.
I work on Julia, not for pay, and something like this only encourages me as it is a strong signal of demand by Real People writing Real Code.
> Not quite sure why this isn't a more common situation for open-source, it seems like the ideal situation for everyone.
Because it's hard to do. I've been trying to figure out how to do it too for a while, but first of all you gotta wrangle a bunch of developers, a large part of which don't actually want to have any actual responsibility with the project. Many of even the most core developers see it as a hobby.
Then, finding customers isn't easy. It's not just a matter of putting a "Support And Consultancy For Sale" sign on your webpage. You gotta have a nice website, and you have to go and convince people that their money is well spent. And you have to make sure you have the proper infrastructure to handle those requests.
And once you find customers, you have to figure out how to spend that money. As the root of all evil, it can lead to tensions between developers. What used to be just for fun is now a job. This may actually demotivate them. And they might now have to concentrate on tasks that pay instead of tasks that are merely fun. And they might resent how the money gets distributed.
All of these problems can be surmounted, of course, but it's not at all easy, and it involves a set of skills most free hackers don't have. We'd rather be coding than running a business.
idunning this is very well articulated. We are completely committed to open source, and working for ourselves just is so much better.
As for JuliaBox, we are grateful to AWS for the credits. They rescued us once, but going forward, we have to figure out a way to make it self-sustaining. I feel it is reasonable to have some level of sustainable free JuliaBox access, with charges for higher compute and storage - kind of like github, although it is not an apples to apples comparison.
Great news. The core developers had said that this was in the works at last years JuliaCon. Now they can make a living through consulting while continuing to work on Julia.
Very misleading title. Wanted to read the article, was hit by yet another story that wants to be a minor novel before it gets to the point, and then skipped reading the article because... effort. Was left with the impression that you would now have to pay for using it and only upon reading the comments I finally get what it is they're doing.
This seems a little hasty on the part of the Julia guys. This is a promising language and I for one was looking closely for alternatives to Python. Yet Julia hasn't built enough traction yet, and here we are with a commercial arm run by all the founders, already. There is of course nothing wrong with wishing to monetize one's hard work, but I fear that the OSS community will now shun Julia because they'll be afraid that new features might be added only to some commercial version in the future, and/or, the incentives of the founders will be to make it hard not to pay for consulting. We've seen this before ("Open"gamma, I'm looking at you).
If this were some cloud service with an "enterprise" version I'd be less worried, but when we're talking about breaking into scientific computing against a very entrenched Python/Numpy, and rising candidate Lua, not to mention R, you're going to need as much goodwill as possible from the scientific and academic communities who are so crucial to growing an ecosystem, and many of these are hostile to commerce.
Perhaps the siren song of Matlab's high pricing still sings for Edelman.
I don't know about Matlab... I heard they had a big layoff just recently. So I suspect they might shake things up and make Matlab cheaper.
That said, I recently went from Python to Matlab for the work that I do, I wish I had done it sooner. Documentation is much better, support is nice, and folks in my lab are good at Matlab so I can get quick good help. Bottom line is I get stuff done with Matlab much faster and with better results. YMMV.
That is a decent counterpoint to my original comment I think. I work with clients who are very happy and very productive with Matlab, precisely for the reason you cite: fantastic docs and support. I just cannot justify the huge spend on every new module, nor is Matlab an option if you want to distribute software widely. Also my sense is that the somewhat more chaotic world of Numpy is more innovative, if less stable and user friendly.
But I definitely think there is a strong case for high cashflow when it comes to supporting a technology. Perhaps this might be good for Julia if (and only if) they can keep the OSS people motivated and onside.
I'm curious why you consider Matlab not an option to distribute software widely? They have the Matlab Compiler that allows you produce executables that work with the freely downloadable Matlab Compiler Runtime.
I know of at least one software product, Imatest, that is produced and distributed this way.
I am given to understand that some functionality is not compilable or redistributable. I work in a fairly specialized field (fixed income term structure optimization) and this page is not encouraging (see "cannot be compiled" column):
Also, finance is a field ripe for disruption, and if you're going to disrupt, you probably don't want to be doing it by relying on an expensive piece of highly proprietary technology, is my view.
I suppose that ties into the whole trade off one has in using Matlab in the first place: locking in to a proprietary commerical product to spend more time on problem-space work and less on managing memory and I/O etc. You get to pay up front to get working on your problem more quickly, and you pay again later on with a potential lack of flexibility.
I have been burned by such a lock in before in a personal project where the commerical make an app easily SDK was discontinued and left in the dust with all the developers left holding their collective unupdateabale apps in their hands.
They have carefully left out certain key capabilities in the Matlab compiler, that renders it not very useful for some applications. So it is cool, but check the list of compilable functions.
TL;DR: "They have launched a startup, Julia Computing, to provide services such as support, training and consulting services for Julia, for a fee."
Basically, consulting and services. For all those who're getting worried by this, I don't think there's any inherent problem. After all, this is exactly what Red Hat has been doing with Linux for years.
Honestly, I still feel a bit uncomfortable when hearing about something like that. When a company (especially if it's a company making a software product for "internal" use, like programming language or monitoring service) provides "support and training for a fee" I cannot help but imagine how all the documentation disappears or becomes more and more outdated, until only enterprise customers are using that stuff. Because if you are paid for training, why would you care to teach people for free, right?
Of course it's probably only my imagination, but… that's it.
The documentation is community created and under the MIT license as is the rest of the code. Our customers like Julia because it is a high quality open source project. Our incentives are fully aligned to make Julia the best open source project it can be, in all aspects.
I did not work on Julia for the last 5 years to see it become cripple-ware. I have worked in a startup before where all the amazing engineering work disappeared. That is why we started Julia in the first place.
Hm, how did they get the initial funding? I want to do the same thing for Octave, for which I'm sure a similar market exists, but I have no idea where to get the money to get started. This isn't a startup that just grows indefinitely. It's not a build once, sell infinitely often kind of thing. Each contract requires constant labour and upkeep.
So how did they manage to attract a hedge fund? And are they losing any autonomy in that? Also, will this distract them by making them work on customer-specific software and installations instead of working on Julia itself?
yeah... raises a lot of questions, did they blog somewhere about what they're doing? which hedge fund? how is it going to help/change evolution of the platform?
Does it matter which hedge fund? According to the article, the hedge fund offered them a contract for what seems like an open-ended engagement while simultaneously encouraging the core developers to go out and raise funds. Seems like Julia Computing partners decided not to raise funds and instead are trying to bootstrap themselves as per the article quote:
"The startup is currently completely bootstrapped and has about a dozen employees including the founders, with no immediate plans for raising funds."
The term "startup", probably chosen by the publication and not by the consulting practice partners, is definitely confusing. However, since Shah also discussed potential products that the LLC would be trying to commercialize, the choice of words and resultant confusion is understandable.
Stefan Karpinski lists himself as a founding partner as of 2013[1], so the idea has clearly been percolating in the back of the core developer team's heads for a while, and rightly so since how else can they sustain the development of the language full-time?
Yup, Julia Computing has been around for all of last year, and it has been publicly known, but perhaps not widely, as I gather from the comments here. We talked about it at JuliaCon 2014. See: http://juliacon.org/2014/
The terms are used a bit loosely. Commercial support is what I think of as a scalable product, which is different from consulting and training, which are services we provide.
Having Julia Computing has meant that we can do Julia for a living, helping our customers who also love Julia. A win-win!
If the 'NY hedge fund' can be publicly named / give an endorsement, it would drive adoption in other hedge funds and financial applications. It's a pretty small universe and surely one thing holding back adoption is confidence that it's production-ready, availability of a pool of people who use it, etc.
By developing a language that's well suited for work the hedge fund wanted to do, I expect. Imagine you're a hedge fund; you have quants building models using maybe Python and MATLAB, and maybe production software in C++. A language that offers MATLAB-like conciseness for array operations, Python-like decent language design generally, and not-so-far-from-C++-like execution speed is going to be very interesting.
But it's still a newish language, not perfectly mature, and you're worried about running into bugs. You would prefer those bugs to get fixed, preferably quickly.
Bankrolling the Julia team seems like it could be a pretty good move.
I'd suspect that an organization with the money to bring in a contractor is not too far removed from an organization with money to buy matlab licenses.
Julia is an extremely ambitious project -- more so than most other languages being developed now, due to the number of things they're trying to do, and the novelty of Julia relative to previous projects.
I used Julia for a couple of toy projects, but I then started running into various odd bugs in the language and libraries, so I stopped using it.
It's great news for me that they're starting a company, and the core developers will have the opportunity to step up development as part of their livelihood. I hope they hire some full-time developers to iron out all of the kinks.
This was hinted at Chicago's JuliaCon about some consulting work. Some of the JuliaCon participants brought up a question - "I love Julia, etc, but how can you convince me that this isn't going to be dumped once you guys all get bored?" - IIRC, Jeff Bezanson replied something along the lines of "I love this project and I'm comfortable starving on ramen while I work on this". Which is a noble thing for Bezanson to say, but actually made me nervous about Julia's future.
Considering it's obvious Bezanson and many of the core contributors works on Julia full-time * 2, I wasn't quite sure how he paid rent/food. And since everyone needs to pay food/rent ... this seems a very good thing for the contributors to continue working on Julia.
If you told me that the core developers were planning to eat ramen for years on end, I'd be very worried for a new language. Instead, this strikes a great balance for Julia to advance and keep the lights on.
> Second is in the embedded (devices and platforms) space ... It is almost ready -- so in theory, by next year, Julia could be working on the iPhone and Android platforms.
Regarding Julia on Android and iOS, Julia was recently ported to ARM v7 via a Raspberry Pi 2. I wonder what the other barriers are for getting it to run on a mobile OS?
are there any material differences between Julia Computing for Julia and TypeSafe for Scala? From my reading of the OP i didn't see any; if there are not then i should think this is a good thing for Julia.
41 comments
[ 3.0 ms ] story [ 75.1 ms ] threadAlso, I wouldn't call it a startup, it's more a consulting company.
As for the book with Nilekani, that's about the intersection of governance and tech in India. What does that have to do with Julia?
Julia and JuliaBox are both MIT Licensed: https://github.com/JuliaLang/julia/blob/master/LICENSE.md https://github.com/JuliaLang/JuliaBox/blob/master/LICENSE.md
The only factual content I was able to gleen from the article was that they plan to have a paid offering for: https://www.juliabox.org/ ?
- They would have had to go work for another company that doesn't care about Julia. Its now a free time project.
- They would have had to go work for another company that does care about Julia. They get to work a bit on Julia, but focus shifts to what this company cares about.
- They work for themselves.
Not quite sure why this isn't a more common situation for open-source, it seems like the ideal situation for everyone.
I work on Julia, not for pay, and something like this only encourages me as it is a strong signal of demand by Real People writing Real Code.
Because it's hard to do. I've been trying to figure out how to do it too for a while, but first of all you gotta wrangle a bunch of developers, a large part of which don't actually want to have any actual responsibility with the project. Many of even the most core developers see it as a hobby.
Then, finding customers isn't easy. It's not just a matter of putting a "Support And Consultancy For Sale" sign on your webpage. You gotta have a nice website, and you have to go and convince people that their money is well spent. And you have to make sure you have the proper infrastructure to handle those requests.
And once you find customers, you have to figure out how to spend that money. As the root of all evil, it can lead to tensions between developers. What used to be just for fun is now a job. This may actually demotivate them. And they might now have to concentrate on tasks that pay instead of tasks that are merely fun. And they might resent how the money gets distributed.
All of these problems can be surmounted, of course, but it's not at all easy, and it involves a set of skills most free hackers don't have. We'd rather be coding than running a business.
As for JuliaBox, we are grateful to AWS for the credits. They rescued us once, but going forward, we have to figure out a way to make it self-sustaining. I feel it is reasonable to have some level of sustainable free JuliaBox access, with charges for higher compute and storage - kind of like github, although it is not an apples to apples comparison.
If this were some cloud service with an "enterprise" version I'd be less worried, but when we're talking about breaking into scientific computing against a very entrenched Python/Numpy, and rising candidate Lua, not to mention R, you're going to need as much goodwill as possible from the scientific and academic communities who are so crucial to growing an ecosystem, and many of these are hostile to commerce.
Perhaps the siren song of Matlab's high pricing still sings for Edelman.
That said, I recently went from Python to Matlab for the work that I do, I wish I had done it sooner. Documentation is much better, support is nice, and folks in my lab are good at Matlab so I can get quick good help. Bottom line is I get stuff done with Matlab much faster and with better results. YMMV.
But I definitely think there is a strong case for high cashflow when it comes to supporting a technology. Perhaps this might be good for Julia if (and only if) they can keep the OSS people motivated and onside.
I know of at least one software product, Imatest, that is produced and distributed this way.
http://www.mathworks.com/products/compiler/
http://www.imatest.com
http://uk.mathworks.com/products/compiler/supported/compiler...
Also, finance is a field ripe for disruption, and if you're going to disrupt, you probably don't want to be doing it by relying on an expensive piece of highly proprietary technology, is my view.
I suppose that ties into the whole trade off one has in using Matlab in the first place: locking in to a proprietary commerical product to spend more time on problem-space work and less on managing memory and I/O etc. You get to pay up front to get working on your problem more quickly, and you pay again later on with a potential lack of flexibility.
I have been burned by such a lock in before in a personal project where the commerical make an app easily SDK was discontinued and left in the dust with all the developers left holding their collective unupdateabale apps in their hands.
Basically, consulting and services. For all those who're getting worried by this, I don't think there's any inherent problem. After all, this is exactly what Red Hat has been doing with Linux for years.
Of course it's probably only my imagination, but… that's it.
The documentation is community created and under the MIT license as is the rest of the code. Our customers like Julia because it is a high quality open source project. Our incentives are fully aligned to make Julia the best open source project it can be, in all aspects.
I did not work on Julia for the last 5 years to see it become cripple-ware. I have worked in a startup before where all the amazing engineering work disappeared. That is why we started Julia in the first place.
So how did they manage to attract a hedge fund? And are they losing any autonomy in that? Also, will this distract them by making them work on customer-specific software and installations instead of working on Julia itself?
"The startup is currently completely bootstrapped and has about a dozen employees including the founders, with no immediate plans for raising funds."
The term "startup", probably chosen by the publication and not by the consulting practice partners, is definitely confusing. However, since Shah also discussed potential products that the LLC would be trying to commercialize, the choice of words and resultant confusion is understandable.
Stefan Karpinski lists himself as a founding partner as of 2013[1], so the idea has clearly been percolating in the back of the core developer team's heads for a while, and rightly so since how else can they sustain the development of the language full-time?
[1] http://karpinski.org/resume/
The terms are used a bit loosely. Commercial support is what I think of as a scalable product, which is different from consulting and training, which are services we provide.
Having Julia Computing has meant that we can do Julia for a living, helping our customers who also love Julia. A win-win!
By developing a language that's well suited for work the hedge fund wanted to do, I expect. Imagine you're a hedge fund; you have quants building models using maybe Python and MATLAB, and maybe production software in C++. A language that offers MATLAB-like conciseness for array operations, Python-like decent language design generally, and not-so-far-from-C++-like execution speed is going to be very interesting.
But it's still a newish language, not perfectly mature, and you're worried about running into bugs. You would prefer those bugs to get fixed, preferably quickly.
Bankrolling the Julia team seems like it could be a pretty good move.
It's great news for me that they're starting a company, and the core developers will have the opportunity to step up development as part of their livelihood. I hope they hire some full-time developers to iron out all of the kinks.
Considering it's obvious Bezanson and many of the core contributors works on Julia full-time * 2, I wasn't quite sure how he paid rent/food. And since everyone needs to pay food/rent ... this seems a very good thing for the contributors to continue working on Julia.
If you told me that the core developers were planning to eat ramen for years on end, I'd be very worried for a new language. Instead, this strikes a great balance for Julia to advance and keep the lights on.
Regarding Julia on Android and iOS, Julia was recently ported to ARM v7 via a Raspberry Pi 2. I wonder what the other barriers are for getting it to run on a mobile OS?