OpenSource versus “bloody enterprise” or where the problems with a feature request come from
No cloud solution, unless it is custom-designed, can fully satisfy all consumer needs. Therefore, many at least once sent a feature request to the software manufacturer, or, in Russian, a request to add additional functionality. You may have been in this role too. The manufacturer may include such a request in a product development roadmap. Or send it to the trash. In this article, we will tell you how work with a feature request differs for the creators of solutions based on copied open source products and Enterprise, and what approach we use when updating our platform for building virtual data centers vStack.
Why do manufacturers take on a feature request from consumers?
Feature request – a client’s request to add new functionality to the product or improve an existing one. Customers can use it to influence the development of the products they use and get the features they need. A manufacturer who studies requests is always aware of the current needs of customers. This means that he can improve the product in accordance with real requests, and not taken from the ceiling by the product. As a result, everyone wins. Customers get the features they need, companies get closer to customer needs and outperform less agile competitors.
At the same time, including user requests in the development plan helps to increase user satisfaction and loyalty. Customers see that the company takes into account their suggestions, get the features they need and are ready to continue using the product and recommend it to others.
It would seem that if everything is so good, what can go wrong?
Different approaches to working with feature requests for clones of OpenSource products, Enterprise and ours
Difficulties begin when you send a request to add new features to software developed by a giant company or, conversely, a completely copied OpenSource product. Let’s take a look at the pros and cons of these two approaches to custom requests, as well as how we organized the work with Feature requests on our own platform for virtualization.
The approach of the owners of solutions-clones of OpenSource products
In clones of existing OpenSource products, it makes no sense to accept feature requests from users. Please note that we are talking specifically about cloned products, and not about any software based on open source.
By the way, there have been many more such decisions after the departure of foreign companies from the Russian market in 2022. Products, which are full clones of open source products, grew like mushrooms after rain. Some of them contain almost no native code or contain it in insignificant volumes, which does not affect the functionality in any way. If a company creates a full clone of an open source product, changing only the name and fonts, this means that it will not have the ability to fully control the resulting “product”. We regularly hear the same questions at conferences:How to distinguish a platform that is a full clone of opensource from independent development?“. This suggests that many have already not only encountered problems of this kind, but also managed to realize them, as well as understand the ambiguous possibilities in recognizing such pseudo-products.
In a situation where the software consists entirely of ready-made code, all changes to it are made at the level of the original developers of this code. A client who purchases a full clone of a ready-made open source solution will not be able to quickly get additional functionality. Even if we are talking about minimal changes, the manufacturer will not always be able to quickly make them. At the same time, for the developer of the original code from which the product was completely copied, such a request may be incomprehensible, irrelevant, inconsistent with the product development paradigm or other criteria accepted in the community of developers of the original open source product.
For the sake of fairness, it should be mentioned that such software has its advantages. First of all, it is the speed of its creation. After the sudden departure of foreign players, Russian companies needed an urgent replacement of software with domestic counterparts. And the ability to quickly create an alternative is a significant plus.
However, such solutions often do not have prospects. It takes a lot of effort to make meaningful changes to an opensource clone. Moreover, these efforts will have to be made both at the stage of creating such changes, and at the stage of their transfer on top of a newer version of the original open source product, which continues to develop in its own way in accordance with the paradigm of the original development team. The manufacturer is faced with a dilemma: whether to commit their changes to the original open source product or continue to port them with each new version of the original open source product.
The first option is ambiguous in that:
the original product may not need these changes or even be harmful;
modifications may be required for changes, otherwise they will not be accepted into the original product as not complying with accepted norms and standards, which again complicates their life cycle;
de facto, this means “to give the result of long-term investments to the public plane.”
In the modern world, business altruism is an extremely rare phenomenon. Therefore, many projects that are clones of existing open source products do not work with feature requests from users. The result of this work only increases the amount of changes that the manufacturer has to transfer to the new version of the original open source product. And no one needs this, because it only complicates the whole process.
Why the “bloody enterprise” rarely takes into account customer requests
Submitted a feature request to a large company?
Most likely, the answer was silence or a standard response in the spirit of “We received your request” that preceded it. Why is this happening? In fact, the ability to request additional functionality depends on the policy of the company and its software product. If the work with consumer requests is in line with the goals, resources and priorities of the company, the requester has a chance. However, the likelihood of such a scenario tends to zero, since most large enterprise developers are focused on stability and reliability, and not on new features. And this is logical, otherwise they would not be giants of the market.
In many Enterprise companies, the processes for accepting new functionality into development are so formalized and centralized that even applications from large customers have little chance of getting into the roadmap. Any consumer requests to add features here will be a drop in the ocean. Often such products are already overloaded with an excessive number of functions in the implementation of the same tasks. The manufacturer adds to them not just the maximum, but often an excessive number of features aimed at solving the same problem. In this case, the client will use no more than 10% of them, and will need to pay for the entire set of features and options. With each update, the developer will add new, not always needed functions that will only make the product heavier, more resource-intensive and expensive.
And what about yourself?
It’s time to tell you how we built the work with client requests on our platform vStack. We are not (yet) market giants and we are not a clone of an OpenSource product.
The platform was developed by Russian specialists and is developing independently, taking into account the wishes of real consumers. vStack is completely our own development, which was created as a replacement (but not a copy!) of the platform of the American company VMware. VMware has many features, but the reality is that 90% of consumers use only about 5% of them. We decided to go the other way and stop adding redundant functionality. If the client lacks some features, he can send us a personal request for their development.
One of the clients vStack — the international hyperscaler Serverspace, regularly sends us requests for the addition of certain functions. Until 2019, the company built infrastructure based on VMware virtualization solution. However, maintaining the platform required a large investment. And when Serverspace needed features that VMware didn’t have, they weren’t available. Therefore, the cloud provider turned to us and, in fact, influenced the development of vStack. Most of the changes to the platform in 2020-2022 came as a result of processing requests from the Serverspace team. However, other customers are not required to pay for these upgrades at all. Each company can choose any set of features it needs and not pay for everything else.
What problems does not work with a feature request create?
“The requirements for the new system will not be known until it is in use.”
Watts Humphrey, engineer, “father of software quality”
In our opinion, the lack of work with requests creates problems for both software product manufacturers and their customers. If everything is more or less clear with customers, they will not receive the necessary functions and, possibly, will pay for unnecessary ones, then everything is not so clear with the manufacturer.
If a company does not process feature requests from consumers, product development may not go in the direction that is relevant for customers. As a result, new features will appear that do not meet the needs of users. There are many examples of enterprise-level products that have “lost their way” and disappeared in this way.
On the other hand, the constant processing of customer requests can greatly distract from work on the main tasks. If you get bogged down in these requests, you can move away from the initial development strategy and spend time adding features that will only be needed by a single company. The question of how to find a balance remains open, and its solution is exclusively in the plane of the resources available to the developer company.
