What Should ComponentOne Have Done?

At this point, because of my posts here, here, here, here, and here, and the fact my company is a reseller of components at VBxtras and Xtras.Net, you probably think me to be a shill for the component industry.  Unfortunately, I’m far too idealistic for that to be true. :-)

 

I think ComponentOne was justified in how they handled Robert McLaws’ situation, which is not what I get from reading Robert’s post, but from a public relations perspective I think they bungled it.

 

First and foremost, I think Mike Sax said it well: communicate policy before the customer purchases.  In Robert McLaws’ case he got ComponentOne’s software for free included in the Microsoft VB.NET Resource Kit.  ComponentOne should have made it abundantly clear to anyone using the software that it was provided as-is and that any bug fixes would require a subscription purchase.  My guess is via oversight they probably did not ensure the policy was known to everyone using the software (i.e. a good way would be a nag screen that makes it clear and requires the developer to acknowledge by typing “yes.”) That would have set the expectation.

 

However I will beat on Robert a little bit here. Even though ComponentOne should have set expectation for their own benefit, Robert should have done his due-diligence before including ComponentOne’s software into their app. By not proactively doing so he created a project “risk” and as such some of the blame should fall on him. 

 

Please note the prior paragraph points out that buying and using component software has risks and as a developer you should fully evaluate those risks before choosing to include a component in your app. (You didn’t expect a component reseller to make that point, did you?  Remember, at the very heart, I’m still a developer. :)

 

Back to ComponentOne: They should have thought through the issue a lot better than they did (though hindsight is easily 20/20. The real question is: How will they handle moving forward?) Telling customers who experience problems with their free version they need to pay for an upgrade sounds like a PR nightmare waiting to explode. 

 

After much thought, what ComponentOne should probably have done was offered Robert an option to get the current build for free OR a subscription for ½ price (assuming they allow their resellers to participate in that too. :-) and ask Robert not to publicize the offer lest everyone learn all they have to do is report a bug in order to get a free update.  Then ComponentOne should have ensured their policies were always made clear moving forward.

 

However, I’m going to give ComponentOne the benefit of the doubt and not because I am a reseller of their product but because that is how I like to treat others; innocent until proven guilty.  My guess is that ComponentOne’s management didn’t perform “an edict from above” to stonewall Robert regarding his needs, but simply didn’t have a good way to bubble up his issue for a decision in an instantly actionable way. The employee to whom he spoke was probably just following written policy that had not contemplated Robert’s situation.

 

Or maybe I’m wrong and ComponentOne’s management just set out to screw all current and potential customers.  But somehow I highly doubt that.

 

What I will do is forward the URL to these posts to my contacts at ComponentOne, and we’ll let them address the issue if they would like. In that manner, maybe I can do what my company always tries to do and that is bring developers together with vendors for the good of all.

Be Careful or you Will Become what you Most Despise

I have been reading Robert McLaws and commenting about his posts for a few days. I was generally commenting about his ComponentOne post and about how from his many posts and his company website how he appears to be a champion for lower prices components. And in many ways I am in agreement with him.

After 10 years in this business, his perspective is one I’ve found to emanate mostly from newer vendors. More established vendors don’t seem to have his same viewpoint.; And I think that is the nature of the beast. A newer vendor often has an ideology they want to pursue (it was true with me.) An established vendor is trying to protect their position and grow it. This is not about good-or-bad, right-or-wrong, moral-or-immoral, or ethical-or-unethical; it just is.

This phenomenon is almost exactly like those covered in The Innovator’s Dilemma. The author Clayton Christensen makes the point that companies are always trying to move "northeast" by which he refers to a graph of increasing margins over time. As challengers offer cheaper products, the natural response for incumbents is to increase features offered while attempting to maintain or increase margins.

Initially incumbents view challengers as unimportant because their products are "not as good" as the incumbents. However, if challengers execute well, their products become "good enough" for the incumbent’s former customers and the incumbents either loose market share or fail. The former challengers then become the new incumbents who then try to "go northeast." Soon the new incumbents are facing their own challengers, and the cycle begins anew. Ironically, knowledge of the phenomenon is far from sufficient to guard it. To understand why, read the book.

In a recent post Robert states (emphasis mine):

I feel that it just lends even more evident as to why it is so important that we really refine the support model, review the issues with products that cause the most support calls, and eliminate them, and adjust the pricing model so that we can afford to support our customers when problems arise.

To that I will say, with absolutely no disrespect to Robert:

Be careful or you will become what you most despise.

Different Component Vendors for Different Developers?

When I started VBxtras in 1994, it was partly because I felt component software was too expensive and I wanted to do something about it. Why? If I couldn’t afford to use it as an independent developer, it was too expensive. I sense Robert McLaws has similar views to the ones I had in 94 as I generally sense that theme in his recent posts and when reading his company’s website.

 

Today I still don’t like it when software is too expensive for me to afford (we work on a shoestring budget here as being a component reseller is not the most profitable business one can pursue), but my 10+ years in the business now has me seeing the issues from multiple perspectives.

 

Robert complained about ComponentOne because their subscription model required him to pay for a renewal in order to fix a bug in a component he was using. As an independent developer I would probably feel the same as he did. However, if I was a Fortune 500 CIO or IT Manager I would want to ensure the vendors of components I used in my mission critical apps were financially viable and hence I’d be more than happy to pay for a subscription. After all, developers costs money and support staff costs money, and someone has to pay for it.  That’s one reason why component vendors move to subscription models; to ensure they have the revenue to support their customers.

 

After reflection on this topic, I believe ComponentOne’s subscription model caters best to companies willing to pay for a higher level of support and that also want to ensure their vendors are financially viable.  Robert’s problem wasn’t that ComponentOne wouldn’t fix the bug; the bug was already fixed. Robert’s problem was that he couldn’t get the fix for free.

 

Which brings me to this hypothesis: Maybe different types of component vendors are better for developers in different circumstances but neither vendors nor developers have really yet made this distinction?  By analogy, what multi-national Fortune 500 corporation would in their right mind attempt to run their business using QuickBooks?  And what mom-and-pop would even consider implementing SAP? Maybe Robert’s problem was he chose to use components from a vendor who is now catering to the SAP crowd and yet what he really needed was QuickBooks?

 

I know from experience many component vendors are “starving artists.”  To service a Fortune 500 company you have to be much more than that.  I seem to remember Robert made several comments in his blogs about software being too expensive and hence his company would offer an alternative. And I know there are a lot of developers as either new vendors and as customers who believe the same, including myself, in some circumstances. So I would hypothesize that vendors with this ideology are the best ones for developers who think fixes should be free. Alternately, vendors that ensure they generate significant revenue are the best ones to services large company’s mission critical apps.

 

If I am correct, then this puts the onus on the developer to know what type of component vendor they are dealing with before choosing to use their component in an application.  What’s your opinion? 

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?

What Responsibility the Component Vendor?

I just read a disturbing post over at Robert McLaws‘ blog about ComponentOne.  Full disclosure for those of you who are unaware, I run a component reseller that sells ComponentOne’s products as well as many vendors. Our websites are located at Xtras.Net and VBxtras.

Robert was upset because he had received a free copy of ComponentOne’s tools included in the Visual Basic .NET Resource Kit distributed by Microsoft and the ComponentOne’s spell check control evidently had a bug in it. When Robert contacted ComponentOne they told him the bug had been fixed and he could purchase an update to receive the bug fix, which he found to be unacceptable.

What is disturbing to me about his post was it raised some interesting and far reaching questions: what responsibility does a component vendor have to its customers, especially if that component vendor provided its component to the customer for free?  And what about when the vendor’s business model is “subscription” where the right to receive updates is included for those that subscribe.  And when someone receives a product for free are they entitled to support and upgrades?

Right now there really are no guidelines anywhere that help both a developer and a component vendor know what should be reasonably expected. If ComponentOne’s response was reasonable, then Robert did them a disservice by blasting them on his blog. If ComponentOne’s response was not reasonable, then ComponentOne did Robert a disservice by not providing him with an update.

I think the issues raised tend to be pretty complex and are definitely not back-and-white. I’m posting this because I’d really like to start a dialog to discuss the issues and collect a large cross-section of opinions.

And BTW, just because my company resells components, don’t assume you know where I personally stand on this issue.  I am first and foremost a developer whenever my reality allows me to be. :)

So, what responsibility the component vendor?