What Can ‘Enterprise Open Source’ Really Do for You?
Vates sponsored this post.
The adoption of the Free and Open Source Software (FOSS) has grown these past ten years. It’s not just that developers now use “Open Source by default,” or that public and government entities are pressured to adopt policies for procurement and in-house development that strongly advocate the principle of “public money, public code.” There’s indeed a general trend towards using FOSS and it is likely to be a great trend. But it does raise a number of questions. Some of the most critical questions are about how companies should rely on and use FOSS.
There are a number of ways FOSS can be used within a professional context:
- Run the software and have it operated and supported by your own internal IT team.
- Buy support for the software directly from a known contributor of the project developing the software.
- Almost the same as the previous one, buy support directly from the company developing the software.
- Use the software as provided by an integrator or a company that has stakes in the software project, in a modified or packaged form.
- An often overlooked model is a variant of the one above — use the software as provided by the platform or service you have subscribed to. This is the case with many cloud services and SaaS companies.
Now each of these possible models has its strengths and weaknesses, but this is where the notion of “Enterprise Open Source” comes into play. After all, what does such a term convey in terms of nuances to open source software, in the absence of a clear label or a clear definition?
A simple way to look at it is by describing the reality of “Enterprise Open Source” as open source software that is used in corporate environments and supported by software vendors or companies directly responsible for its development. The next step is to realize that the enterprise value lies in the ability of software to stay out of the way of the business and be part of the solution rather than part of the problem. More specifically, this means that software should work as intended (more or less well, but likely even better than expected or at least as good as intended) and is properly supported without the corporate user having to make tough choices to source and pay for the support.
Given the definitions above, we can, just for the sake of the argument, exclude the case of Open Source Software developed by the corporate user, in-house or collectively with other contributors. This leaves us, then, with the rather traditional schema of an open source software supported and monetized by a company and used by another customer company. The problem with that schema is that it does not reveal all the possible subtleties and differences that may be at work, depending on the actual role of the company providing support. There are three questions we need answer to understand the kind of value Enterprise Open Source can provide a customer:
- What is the actual role and standing of the company providing support inside the open source software project? Is it one of the main stakeholders? Is it the main author? Is it a renowned expert with a proven track record? Or is it a service provider that is not a major contributor who happens to have some in-house skills and monetizes them on the market?
- Where is the money going? In other words, what does the revenue generated by the support contract(s) directly fund? Is it the development of the software, for instance through the payment of contributors’ salaries or compensations? Or is that revenue getting billed as a pure consulting contract in an otherwise broad range IT shop?
- Last but not least, what is being purchased exactly? In the case of a cloud service provider, the use of a service but not an actual software is being purchased; and even then, that is not a support contract. In other scenarios, the customer pays for a customized version of the open source software, or a packaged version of the software that may or may not integrate proprietary components. Considered in that way, the customer may not always understand what she is paying for.
Based on these three questions, one can see that “Enterprise Open Source Software” neither has a clear definition, nor has a clear value proposition. Relevant and efficient open source solutions for the enterprise may be found, however if the right questions are asked and their answers match the needs of specific corporate environments.
If what is needed is a framework contract that regulates the delivery of deployment, operations and support of a broad range of software stacks, then one should not need to wonder about the value of “Enterprise Open Source Software,” since what matters here is the trust and the relationship, along with the service quality delivered by the service provider. If, on the other hand, one is looking to have top-notch, effective support service delivered by the developers behind an open source software, then it is crucial to pick the right company; and more often than not, that company is the one contributing directly to the open source software considered.
A good example of that is Vates. As the main developer of the XCP-ng hypervisor and the infrastructure management and backup solution Xen Orchestra, Vates is uniquely positioned to help companies and the public sector with their infrastructure needs. It provides support for an infrastructure stack that can run in a variety of use cases and scenarios, but stays out of your way by avoiding the integration of any specific packaged offering. XCP-ng and Xen Orchestra are turnkey in the sense that there’s not much needed to get started and operate them in a corporate environment; in fact, you do not even need Vates to do that!
In the end, what a company is looking for is confidence in its suppliers and its customers alike. How Enterprise Open Source fits in that picture depends on the needs of each company, but the takeaway is that Enterprise Open Source is only as good as the supplier that the customer will agree to work with.
Feature image via Pixabay.