We have seen in this short time of existence that Julia has enabled us (researchers, professionals, etc.) to build very complex software in a matter of months as opposed to years. The package ecosystem itself supports this fact, and we can point to very powerful packages that go much beyond the reach of other programming languages.
Given this pace of incredible work from the community always making things modular, reusable, portable, etc. I wonder what is the business model one should adopt when developing with Julia? How one can make profit out of a very specialized package that is not of general use?
I am active supporter of open source myself and I believe that most packages should benefit from an open development model, however; sometimes we build software at an application level that is not very useful to people outside of a small scientific domain. These I would like to commercialize, but I don’t know how to do so in Julia. Can we provide a compiled version without the code somehow? What are the directions if any that the community is proposing regarding this issue?
One can release software with a license which requires payment for commercial use.
One can use Julia as a backend to a web service.
One can statically compile code.
Other forms of compiling code.
For (1), I’ve seen these kinds of things but am not an expert, but I’m sure Googling around will bring up how this is usually done. For (2), see DifferentialEquations.jl Online as an example:
If I didn’t choose to release the code, this service would be available with a Julia backend and the code would be secure. (3/4), there’s a lot written on this already. Essentially, it’s possible but not easy right now.
I don’t have a good answer to your question, but as a scientist I would be extremely wary of using closed source software that is used by only a handful of people.
Perhaps you could try the following model: make high-quality open source packages that would advertise you are an expert in some domain, then charge money for services (consulting, adding extras to these packages that the buyer would get to use before they are released, etc).
I don’t think the software can be free and open-source in this case (at least, not the full package), because you’d be imposing restrictions on usage.
Several people (including me) use “private packages” which works pretty well using Pkg.clone
In order to make a business of that you need to hide the code, which is topic in
@ChrisRackauckas, I like solution 2) and I have been thinking about it for a while. It would be great to have a tutorial somewhere explaining the packages in JuliaWeb that could be used to fasten this deployment, if there is any.
Compiling the code would also be a solution, and I am looking forward to see what solutions the community will propose.
@Tamas_Papp, I agree in general with your concern, but in many cases the software doesn’t require much training, it is just very specialized and hard to implement. The usage is a simple function call with a few parameters that the user can figure out by him/herself.
Anyways, thanks for supporting open source, I am a big supporter myself too.
This is not my primary concern: for scientific software I am wary of closed source because I like to see the code to learn how exactly it was implemented (and the unit tests, to make sure it is working correctly). For example, calculating standard errors for nontrivial regressions is tricky and there are multiple methods, yet very few software packages document what they did in detail.
I understand your concern @Tamas_Papp, it is valid. I am talking about situations where learning the code is a secondary concern. Your mindset is different than the mindset of average users, and in fact, users from the industry shouldn’t be caring much about internals of a code that took a PhD to develop. They trust in the advancements we are making and want to just get a working software that is easy to integrate with their existing workflows. In my opinion, pin pointing a bug in the code or an incorrect approach is a task reserved to a few of us capable of developing these solutions.