For technical questions, @pavanky is on here :-)
By completely open sourcing your only software product with a liberal license you seem to be turning a software (product) company into a software consultancy, is that a fair assessment?
Do you think the market conditions that lead you to this decision are very specific to GPU computing, or would you expect similar conditions in the more general scientific computing/HPC market? Would you say that it's generally simpler to earn money by doing specialized consulting than by selling technical software libraries, even though the former is less "scalable"?
If you're earning all the money with consulting and support, how do you allocate ressources to the further development of the library? Do your software engineers enjoy working on your company's product the same as working on client projects?
I bet the market conditions that led to this are broader than just GPU computing. I think it would more generally apply to any middleware business. But it is certainly more palatable for people in scientific computing and HPC to use something free and later pay for support and services and addons. Once people start really relying on the free thing, that reliance can be monetized. In this sense, it is more "scalable" to have an open source product which is readily adoptable by early users than to attempt to sell a product to buyers that have not yet started to rely upon it and have a good distance to go before reliance sets in. This is not SaaS and never will be, haha.
Allocation of future resources is something that we have considered a lot. I wrote before about opportunity costs associated with an open source business model: http://notonlyluck.com/2014/08/13/opportunity-costs-required...
We just open sourced today, but our plan is to treat the open source product the same as we have always treated it even when it was proprietary.
Great questions! Hit me up on Twitter @melonakos. Would be good to connect more with you, especially if you are going to SC'14 next week.
I do think that libraries should be distributed as open source, but I'm also hoping that at least in certain areas there is a way to commercially develop them as a product business. Provocatively speaking, if software "eats the world", then libraries are too important to just be developed as a by-product of some other ventures or in support of a platform/eco system.
Personally I'm planning on releasing a library under a GPL + commercial dual licensing scheme and later on another library under a non-commercial (incl. academic and government research) + commercial dual license. We'll see how that works out.
> If you're earning all the money with consulting and support, how do you allocate ressources to the further development of the library? Do your software engineers enjoy working on your company's product the same as working on client projects?
This is a question we have debated a lot internally. The shortest answer is that our experience building the product bring in the customers. The customer requirements can drive further development of the product.
Choosing the appropriate open source license (BSD-3 clause in this case), helps us reuse a lot of our code in a wide variety of situations.
If I understand it correctly, since you wrote the code and own the rights, you can do this regardless of the license you chose; e.g., you could have done an AGPL-3 release to the public, and continue giving license-to-use-and-modify-but-not-release to customers.
Am I misunderstanding?
BSD 3-clause on the other hand is very easy to understand and is permissive off the bat.
We need to remove mention of ArrayFire Pro from the website now. Thanks for pointing to that.
- Supports multiple backends, so you can run on NVIDIA GPUs, AMD GPUs, Intel Xeon Phis, and all CPUs using the same API.
- ArrayFire currently has statistics, image processing, signal processing and Linear algebra functions. We are planning to add Machine Learning and Computer Vision functions / algorithms in the near future.
- ArrayFire is a native (C/C++) library. It can be used from other languages fairly easily.
- The main goal is to make parallel programming in general (GPU programming in particular) easier and portable.
update: Downloaded repo, grepped, found externs... looking forward to playing with this :)
Here is the image.h header file for example: https://github.com/arrayfire/arrayfire/blob/devel/include/af...
extern "C" is present on line 58.