What Responsibility the Component Vendor? Part 2, or Subscriptions vs. Bugs

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?

2 Replies to “What Responsibility the Component Vendor? Part 2, or Subscriptions vs. Bugs”

  1. When you buy a car which doesn’t work you would expect it to be replaced with a working example.

    If the model you have bought isn’t available anymore, and there is a new model available which does work.

    Then what would you expect would happen ?

  2. Mischa:

    Interesting point! However, I think you compare apples and oranges.

    Let me extend your analogy. The car you buy comes with a one year warranty and the dealer offers you a manufacturer’s five year extended warranty, which you decline to purchase. You drive the car for 18 months and the timing belt breaks. You ask the dealer to repair it, but they say they can’t since you didn’t buy the extended warranty. Is it unfair for them to decline the fix? I don’t think it fair to the dealer or the manufacturer to have to pay for your broken timing belt after warranty expires because you didn’t contribute to the insurance premium they use to cover the expense of repairs.

    Now, let’s extend the analogy further. The car manufacture tries a new business model where you upgrade cars every year for an annual fee. They run a promo where they GIVE you last year’s model for FREE because they hope you’ll like it and pay to get on the yearly upgrade program. Six months goes by and the timing belt breaks. You say "You need to GIVE me the new model because last year’s model stopped working." They say "We’ll be happy to if you pay for the annual upgrade fee" to which you say "The hell with you, you screwed me by giving me last year’s car that broke! I’ll NEVER buy a car from you." Of course maybe you shouldn’t buy a car from them for reliability reasons (even though this year’s model fixed the timing belts breakage flaw) but I think it would be rather much to blame them for not giving you this year’s model for free.

    I don’t know. Maybe I’ve got a strange view of things but I think the analogy I just described fits and shows why expectations should be different for software sold on subscription. Please note I’m not for or against the subscription model, just trying to document how I think subscriptions differ.

Leave a Reply to Mischa Kroon Cancel reply

Your email address will not be published.