Posted by: Aaron Delp
Cloud Applications, Cloud Operations, DevOps, Open Clouds
There has been a lot of “noise” in the cloud computing community recently that I wanted to write about a bit today. In order to get to my point I’ll have to describe a little bit of background.
The main workflow today is the idea of an “upstream” or “core” code base that is open to all. Depending on the project anyone can download the code and submit changes (think read only access) and these changes will then be reviewed and committed in some fashion back to the code branch (think read/write access). In this model, ANYBODY can pull the code and they can run it in their environment using the “core” or “master” version. For most projects (and users) this is considered great to try and evaluate the project but requires a good bit of in house expertise because the support you will get is from the project and the community around the project. In this example the ownership for support falls to YOU Mr./Mrs. customer.
To increase adoption (and for companies to make a profit) a few alternative profit models have developed to support this. Here are a few of them:
- Consulting Services & Support – In this model a company will take the core code from the project and “package” it for the customer, install it, and possibly support it. They become the “throat to choke” on one side but not the other. This shifts the responsibility and ownership from the customer to the consultant organization BUT if there is a problem with the code, it is up to the project and community to fix it. There is less product to maintain in this scenario and the “secret sauce” of the company is based on their ability to remove operational headaches.
- Create a Product - If the project license supports it, there is the option for an company to take the code and turn it into a product they could then sell and possibly take on all the services as well. In this model they are the “one throat to choke” completely. In this model the company has taken on responsibility for the product as well as all of the support and configuration. In order to differentiate themselves, the company will often “fork” or create a divergent version of the core project to create added value to their product. The company may or may not give this code back to the community. The general consensus is if the code makes the foundation (core) project better it is often donated back but sometime this is not the case.
What does all this mean?
It means there are at least three different models out there today and comparisons between the categories is basically useless. As you evaluate new products and projects based on Open Source, take a moment to step back and think about which category you fall into and if it is a better fit to pursue the same project/product in another category.
Maybe you need some help to get going or you want a lifeline to call for support when the going gets really bad (or maybe your boss insists on it) or maybe you just have a staff that is very active in the community. There is no universal right or wrong answer here. The only answer is what is right for your organization and your unique project.