Making the decision to open source your software is not an easy process. Indeed, here at ArrayFire our choice to release ArrayFire under the open source, commercially friendly, BSD 3-Clause License came only after many hours of consideration and philosophical discussion (e.g. see our CEO’s blog on these topics). Thus far this decision has proven to be strictly beneficial to our company.
The impact of third-party contributions
Although ArrayFire is primarily developed by our engineers, there are several contributions from other developers. Therefore we feel particularly compelled to elucidate how these contributions have improved the ArrayFire ecosystem.
Packaging for Linux and OSX
One of the best parts of open source distribution is that your code can be packaged and distributed for a wide variety of operating systems. We distribute binary installers for Windows, OSX, and Linux (x64), and the Jetson TK1. The Linux and Windows installers incorporate the Intel Math Kernel Library (MKL) and hence perform better than pure from-source builds. The OSX Installer uses the Accelerate Framework to give the best performance on OSX machines. Nevertheless, a few users have taken up the task of packaging ArrayFire for their favorite operating systems. In particular, Ghislain Antony Vaillant created Debian packages for clFFT, clBLAS, and recently added ArrayFire’s CPU backend. After clFFT and clBLAS are accepted his intention is to also package and submit our OpenCL backend to the Debian package repository. (It is unlikely that the CUDA backend will be packaged since CUDA has a license that does not agree with Debian standards.) Around the same time Hugues Malphettes created a Homebrew Formula for installing ArrayFire on OSX from source. Combined with Ghislain’s recent work to package ArrayFire and its dependencies for Homebrew, it is easier than ever to deploy ArrayFire on OSX. [edit… since this post was originally written Ghislain’s homebrew formula has been accepted to the official homebrew-science repository.] Not to be left out of the packaging fun, our own Pavan Yalamanchili recently assumed the role as maintainer for the ArrayFire Arch Linux package.
ArrayFire.js
Among the most fundamental third party contributions is the creation of Node.js bindings for ArrayFire by Gábor Mező. Gábor has previously created bindings for (NOOCL) CMake (CMake.js) and made several contributions to the Foreign Function Interface for Node, node-ffi. In less than a month Gábor created the bindings and contributed it to our GitHub organization. This new ArrayFire.js library lets you use the power of ArrayFire asyncronously from Javascript. We will write more about this project in the future.
Improving the code
Very early on we received input from several developers on how we might improve our CMake build system. Gaëtan Lehmann added CMake project configuration files. which automatically create the equivilant of CMake find scripts. This let us remove our (manually maintained) FindArrayFire.cmake
script. Gaëtan also wins the award for squelching the most compiler warnings by cleaning up 1000+ unused function warnings issued by clang by adding two lines of code. Similarly, Nathan Jackson discovered and fixed a race condition in a reduction kernel, and added several tests for complex values and Filipe Maia added support for s64
and u64
datatypes by contributing six lines of code and fixed missing definitions for some proxy operators.
How can you help?
Like many open source projects, there are many ways to contribute to the ArrayFire library:
Reporting issues
The most fundamental way you can contribute is to use our library and help us find problems and suggest methods by which the library may be improved. Using the ArrayFire GitHub issue tracker you may
- make requests for new features
- suggest performance improvements
- report build issues
- file bug reports
- and report on new hardware/backend support status.
Be sure to read the contributing guidelines prior to submitting a pull request.
Documentation, usage examples, and community help
If you are using ArrayFire and find someplace where you think our documentation could be improved or want to create a new example we would be happy to hear from you. You may submit these improvements through either the ArrayFire GitHub issue tracker or send us a message on the ArrayFire Google Group.
The ArrayFire library also has many methods of providing community-driven help. We would be happy to have your assistance answering questions on the ArrayFire Google Group, Gitter chat, and GitHub issue tracker. If the question can’t be answered here, we also do email support.
Whitepapers
If you have found ArrayFire particularly useful in your field or want to exemplify how ArrayFire has improved your software, considering writing a whitepaper with us! We have written whitepapers on topics ranging low-level memory optimizations for HPC applications to the impact of ArrayFire’s matrix multiplication abilities on high-level language wrappers. We have skilled writers on hand who will work with you to develop a great technical publication. Contact either sales@arrayfire.com or technical@arrayfire.com to get started.
Social media
Help spread the word about ArrayFire by following @arrayfire on Twitter, and ArrayFire on Google Plus. You can also collect some sweet, sweet karma by posting our blogs and progress updates on the /r/OpenCL, /r/CUDA, /r/cpp and /r/programming subreddits and HackerNews
Directly fund ArrayFire development
Lastly, if you are a researcher who uses ArrayFire in your work consider writing ArrayFire in as a subcontractor on your next grant. Similarly, if you love ArrayFire but need some additional functionality fast, consider hiring ArrayFire to write the code for you. We offer a full range of consulting, support, and OpenCL/CUDA/ArrayFire training options that fit almost any budget.
Conclusion
One of the most overlooked benefits of making a project open source are contributions from third parties. Since ArrayFire was open sourced in November 2014 we have received a substantial number of contributions. We have third-parties packaging our software for OSX and various Linux distributions, creating wrappers so ArrayFire may be used in other languages, and contributing code changes that improve our build process. Even a person who does not feel comfortable writing code for the ArrayFire library core may contribute by reporting issues, improving our documentation, answering questions on our Google Group page, collaborating with ArrayFire LLC to write whitepapers, talking about us on social media, and even directly funding development of the library through ArrayFire’s consulting, support, and OpenCL/CUDA/ArrayFire training services.
Comments 4
We all wish you success with your move.
I think it is the right move.
I can suggest you making partnership with some of the hardware review sites (Anandtech, Tom’s Hardware, Tech Report, etc…).
You can create a simple program (OpenCL) for them to test computing performance of GPU’s.
They will benefit a special sauce int their performance review suite, the readers will get another perspective on their GPU and you will get more exposure for technical people.
You should try…
I’ve also added the external projects for clFFT and clBLAS, to make easier to build arrayfire from source, and packaged arrayfire and its dependencies for homebrew (https://github.com/Homebrew/homebrew-science/pull/2353 and https://github.com/Homebrew/homebrew/pull/37928), even if it has not been accepted yet.
I wish all the best to arrayfire as an open source project! It is always a pleasure to (modestly) contribute to a great open source project 🙂
arrayfire is now officially packaged in homebrew science!
Indeed! I actually updated the blog post last week to reflect this. Well done!