Open Source MPI Implementations
People periodically ask about my opinions of closed source forking from the open source project that I work on (Open MPI). “Doesn’t it bother you that others making money off the software you wrote?” they ask. “Aren’t they taking credit that belongs to you?” And my personal favorite: “Don’t you worry about losing control of the Open MPI project?”
My answers to these particular questions are:
- No. And to be clear, I’m part of a community that wrote the software — I didn’t write (anywhere close to) all of it.
- No, they’re not. They’re exercising the license that we chose to use (BSD).
- No. There are good reasons both to extend and/or fork from our code base.
To be clear: I think that all the work — both open and closed source — surrounding the project and community that I am fortunate enough to be a part of is GREAT.
Having lots of people work on a project — both collaboratively and separately — gives a project vitality and continuity. It seems fairly obvious to me that if a project starts small, but over time wins the hearts and minds of a sizable community, then it might be a pretty good project. Indeed, that’s exactly how Open MPI grew from a tiny research effort shared between four academic/research organizations to the world-wide brand name recognition that it has today.
The commoditization (is that a word?), popularity, and competitiveness of HPC itself has given rise to many products and services in attempts to woo customers. Some of those products and services build upon our code base. For example, there were announcements at both SC’09 and the OpenFabrics Sonoma workshop about vendors exploiting the secret sauce in their hardware with Open MPI. Since vendors generally do things for a reason, I think that this may be indicative of several things:
- There is consumer demand (e.g., people asking for Open MPI).
- There is a solid code base to build upon (i.e., lower investment/time to completion, both in terms of implementation and overall quality)
- There is a good reputation (i.e., Open MPI is receptive to both external input and vendor-specific secret sauce)
Increasing the size of the Open MPI community is a Good Thing. If nothing else, it increases the level of care and feeding that is given to the code base over time. Think of it this way: even closed source vendors need Open MPI to continue as a viable project (otherwise they’d have to do all the work themselves).
Every participating organization contributes in its own way. We all have our own agendas, but we work together on a common code base with a few common core ideals. As I have said before, heterogeneity of opinions in a community is good. Similarly, having diverse distribution mechanisms and development models is also good.
All of these factors, taken together, indicate to me that the Open MPI community is strong, vibrant, and actively engaged in continuing to make Open MPI a great product.