It may not always be appropriate for a container to have an open-ended specification that caters to many different locales and requirements. In this case, building custom software to fit your needs can be a good approach. Doing so has a number of definite benefits for container implementers:
The software will be highly targeted for your container’s specific needs and requirements, thereby reducing code bloat and unneeded features.
The code base is divorced from the requirements of an open specification. This means that if a change is needed in the code that conflicts with the initial development specification, you can make that change without having to contribute it back to the open specification (and working to get it standardized in future versions) or having to maintain the code differences from the specification when you upgrade to new versions.
These are definitely powerful drivers for many development shops. You are building a project that exists within a silo, separate from the rest of the world. However, there are also a number of drawbacks to this approach:
You have to develop all code in-house or for the container itself. Since this is a proprietary code base, you’ll have to devote engineering time for all upgrades and new features.
The company must offer support mechanisms for developers building on top of the platform. The community of integration specialists on the particular platform will not include other companies or developers who have implemented ...