##CONTINUE##
When the Free Software and Open Source movements started, the question was always "How do you make money?". The answer was you give away the software and sell support and services. It is this simple business model which has been evolved by the current set of open source based Enterprise software vendors. Many vendors say their software is open sourced, but that isn't an assurance that as a customer you'll get the benefits of open source.
Let's talk about Example Corp, a hypothetical open source enterprise software vendor. Example Corp, at first glance, seems to be what it says on the tin. Our hypothetical company makes a software product by the name of Examples and has web sites Example.com where it sells subscriptions to Enterprise Examples, and example.org where the community edition of Examples is made available. On the face of it, this looks like it should be fine. An enterprise can try out the community edition and if it works for them buy a subscription for support for Enterprise Examples.
The existence of a community edition though doesn't guarantee there's no trap. Let us consider ACME, a company wanting to move to open source in their enterprise. The IT department at ACME have found that Enterprise Examples has all the features they want and goes ahead and purchases a subscription. They install it and something goes wrong. The open source way should allow them to look at the code, fix the problem and put a new version in place. However they bought Enterprise Examples and the support subscription for that says "We only support the compiled versions we have supplied", so ACME get on the phone and get Example Corp to fix the problem and supply a new version which they will continue to support.
Sound familiar? Yes, it's the classic way of supplying proprietary software to a company. This is the "limited support lock in". By only supporting binary versions that they have supplied to enterprise customers, Example Corp have taken away the advantages of open source from the customer. What open source does for Example Corp is give them a cheaper way of developing their software by allowing people to take the community code and enhance it, and they get the benefits of those enhancements. The ACME folks don't get to benefit from this apart from being able to look at the public source code as part of the diagnostic process, but the source code isn't open source but more "visible source". This in itself is useful, but isn't the same as having the freedom of open source.
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.
Open source check list
There is nothing wrong with a company wanting to keep customers and partners, but it is somewhat counter to the term open source and at odds with the term free software. An enterprise has to be prepared to ensure that the enterprise open source vendor they are dealing with is really as open as they need.
Here's a checklist of questions to ask :-
1. Does the vendor offer support for the community version of the product?
2. Do they offer that community version support on a per-incident basis?
3. Is the same feature set available in the community and enterprise versions?
4. Is the enterprise version free of proprietary components? If there are any, are there open source replacements for them?
5. Under an enterprise subscription, will the vendor make best efforts to support modified versions of their product?
6. Is the enterprise products source code made available to the customer in its entirety (or only the components that are present in the community version)?
7. Are the vendor's partners allowed to install and work with the community version?
8. Can a customer, if they want to, replace a typical enterprise installation with the community version?
9. Are there people other than the vendor's employees contributing to the community version?
If the answer to any of these questions in "No", then it is worth digging deeper into how much freedom the enterprise version of a product gives you. Although "freedom" with software is a somewhat abstract concept for the enterprise, and always rates quite low on enterprise open source surveys, it does affect the total cost of ownership. The lock ins outlined earlier could increase sunset costs, the ability respond to new requirements or the availability of expertise with the product. Just because a company has a product with a version under an open source licence does not make the company operate on the lines of an open source community. If customers are to get the full life-cycle benefit of open source, they need access to all of the freedoms that it implies.
-----------------------------BY Dj Walker-Morgan
Source：THE H-OPEN
Copyright © 2009 Heise Media UK Ltd.
Posts
0 comments:
Post a Comment