Robert McLaws responded to my post from yesterday about the responsibility of component vendors. Robert’s comment reflected his view as a vendor (Robert sells components too, though my company hasn’t currently established a relationship with his company via Xtras.Net for no other reason than I just learned about his products.) Robert states:
I believe that is the vendors responsibility to take care of their customers, whatever that means. If a function in the API does not work, then a customer should be able to get the update for free, as long as it is the vendor’s fault, not the customer’s.
I tend to agree with that assertion, especially in principle. However, what defines the limits of "taking care of" in the software context? ComponentOne has a subscription model which differs from selling versions of a component as Mike Sax elegantly explained. This might bring up another question about which I’d be interested in hearing opinions: “Does a subscription model provide a disservice to the customer?” As is, I’m going to assume a subscription model and use Mike Sax’s comments to define the model.
On subscription you get updates rights when you buy the subscription. If your subscription is not current, there are no new update rights. A grey area would regard a prior subscriber’s right to access to the latest update made available prior to their subscription lapsing, and I strongly believe vendors should allow that. For example if there are 4 quarterly updates and I purchase an annual subscription in Jan 2004 which gives me Q1-2004 through Q4-2004, in 2005 and beyond I should still be able to download Q4-2004. But that’s not Robert’s issue.
Looking at it logistically; I see two ways ComponentOne could have solve Robert’s issue. First, they could apply all bug fixes on all prior subscription releases. Assuming quarterly subscription releases, a year would require they apply each bug fix on four code bases. After two years, they would need to apply each bug fix need on eight code bases. And so on. Is it just me, or does the combinatorial explosion this creates prove it to be unworkable?
The other way is to just give the customer the new release, the one he didn’t pay for. If we follow Robert’s customer service rule, then anyone who experiences a bug should get the latest version for free. And that might be a great customer service; I would applaud any component vendor who would choose that as a policy, but I would also question whether it would be viable long-term.
As I believe no software is bug free then who would pay for a subscription renewal when one only needs find a bug, even if that bug isn’t affecting them? But them I’m sure there aren’t any developers reading my blog that avoid the subscription fees in this manner, right? :)
So is my analysis correct? Is a policy of providing the most current version of a subscription to a developer who finds a bug incompatible with the subscription model? I unfortunately think it is. What is your opinion?