Julia founders commercialize language, create new startup
economictimes.indiatimes.com
economictimes.indiatimes.com
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.
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.
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://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.
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.
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?
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.
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?
Also, 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?