« previous 1 2 3 next »

Another scenario

Another scenario would be where a security problem was found with Examples; the users of the community version could patch as soon as a patch was available, but the enterprise users would have to wait for Examples Corp to issue a new supported fixed binary. In an ideal world, this time difference should be negligible, but for the enterprise version the ability to patch problems quickly as a user is not present.

Later on, ACME wants to add some functionality to Examples, so it downloads the community edition of Examples and starts working with it. Then it's discovered that community Examples isn't functionally the same as Enterprise Examples, which came with features such as clustering, high availability and other enterprise level features. These features are only in Enterprise Examples and are added by Example Corp as part of their enterprise offering. This is the "feature lock in". Although the core of the package is open source, the parts related to deployment and management for example, are more proprietary than open.

The ACME developers consider the problem and decide to push on and start adding the functionality to community Examples. They have some success and decide they would like to deploy their version, ACME Examples, alongside their Enterprise Examples system. But remember that problem with no support for "own-rolled" bug fixes? Well, the same thing applies here on a bigger scale. Example Corp say they won't support it, even the unmodified parts.

The ACME developers decide that they will check in their enhancements into the community version of Examples and wait for Example Corp to release their next Enterprise Examples release. Whenever that is due. When it does arrive, the next version doesn't have their enhancements, as Example Corp's developers didn't want to incorporate them because ACME duplicated the functionality of a separate product Example Corp already markets, albeit on a smaller scale.

At least ACME didn't become a partner of Example Corp. Partners of the hypothetical Example Corp are required to sign a partner agreement which says they can't install or work on the community version of Examples. The reasoning is simple; Example Corp support the partner and provide resources for them which in turn costs Example Corp who don't want the partner undercutting their enterprise version by installing the community version at customer sites. It's a reasonable position, but there is a trap for the partner; they can't work on the community version and enhance it. They could make changes and pass them back through Example Corp, but the partner can't just participate in the community. This is the "partner lock in" and it is worth noting as a customer of that partner as they may be limited to only offering the Enterprise version.

The same can apply to enterprise customers who can't, because of what we have previously mentioned, work on the community version because they wouldn't be supported. Without these customers contributing, the community contributing to the product could well be made up of only the developers of Example Corp.

Next: Open source check list

« previous 1 2 3 next »