Starting a New Chapter in Life…

Those of you who follow my blog are aware it has been a long time since I’ve last posted. Some of you already know what has been going on in my life, but most of you don’t. For those of you who do not as well as the rest of you it’s time for me to fill you in. 

But let me start with some background. Back in 1994 I founded Xtras, Inc. (then as VBxtras, Inc.) and I proceeded to grow it like mad. Then in 1999 Inc. Magazine honored us with their award for fast growth, placing us as #123 out of 500 on their Inc 500 list. It was a wild ride and I loved almost every minute of it!

Probably the best part were the people who honored me by working for Xtras during that period. I’m going to name a just few of them; the ones who contributed something so critical that Xtras would possibly have never succeeded had each of them not been involved (I’ve linked to their website or blog if I was able to find one):

Without each and every one of them, Xtras would never have reached the levels of success that it did. They helped me fulfill a dream; I thank them so muchl.  But there were also many other fabulous people who worked for Xtras from 1994 on, and I value every last one of them too. So if you dear reader are any one of them, please accept my thanks and forgive me for not mentioning you personally; you were very much appreciated.

In addition, there are also many fabulous vendors/catalog advertisers that Xtras dealt with during the VB3/4/6 heyday (1994..1998) when there was so much energy surrounding the Visual Basic industry. There was an almost all-for-one-and-one-for-all kind of feeling in the industry during those early days, which unfortunately does not exist in the Microsoft add-on vendor community now. To find something similar, sadly you have to go to the Web 2.0/Ruby on Rails crowd to get the same vibe.

Back then it was the people that made it so great, back before everyone started guarding their vested interests, back when it was Sheridan Software and Crystal Reports, not Infragistics and Business Objects, for example. Back when we were all about building an industry together. So I’m going to name the names of the people I remember, but there’s a good chance I’ll screw up and forget somebody because there were so many more people involved back then. So here goes, with links to their current blog if I could find one, including their company at the time (and the company it became if applicable), with links to whatever companies still exists. In no particular order, of course.  And anyone that’s forgotten, I apologize in advance:

Anyway, about the same time Xtras’ growth spurt peaked (around 1998/99; Xtras having been underfunded, I might add), the dotcoms boomed and, as I’m sure everyone remembers, VCs threw far too much money at companies without business models, none of them having being Xtras. This led to Xtras’ stasis; our inability to grow Xtras’ business and for the next six, we just operated pretty much doing the same thing over and over, day in and day out. Of course I wanted us to try new things, but we someone never managed to have the resources, and/or I could never manage to rally the troups.

So in May 2006, I left Xtras. I left to decompress and to clear my head. After a little over twelve (12) years of running Xtras I made a deal with one of my shareholders to buy my stake in the business and now Bill Kaylor has taken my place as president of Xtras. I wish them luck, but at this point I have no involvement and absolutely no financial interest left in Xtras. Of those twelve years, the first five (5) were some of the best years of my life, and last seven (7) were some of the worst. Be that as it may, plenty of fodder for future "lessons learned" blog posts. Although I have been working a little since May, I’ve mostly been catching up on things I neglected for so long, including renewing old friendships and cultivating new ones.

But now that I’ve had a short breather, I’m ready to leverage both my 19 years of business and marketing experience and my 21 years of technical/developer experience to pursue exciting new ideas and to once again work with the bright, enthusiastic and highly motivated people that make work so much fun. But you might ask why leaving Xtras will allow me that? 

The plain fact is a reseller like Xtras has a high number of customer transactions, is capital intensive, runs on low margins, and is held in pretty low esteme within the industry. In the early days we published a printed catalog which was the guide for the industry, but the Internet and Google replaced the need for that, so we devolving into being "just a reseller." After many years of metaphorically banging my head against the wall I realized it was virtual impossible for me to devote the time, find the funding, and/or gain interest from the people needed to form the loosely-coupled business relationships.that work so well to pursue the incredible Web 2.0 opportunities that are presenting themselves today. So it was better for me to just leave Xtras in other’s hands and start anew.

In what areas do I want to focus? I want to improve the world! I want to make things and life better, faster, cheaper, easier! Heck, if I could devote my life to world peace with 100% certainty, I would do that!  I have several projects in mind, some are for profit and some I have absolutely no profit motive whatsoever. For the latter I want to be a catalyst just to see them happen as I believe my doing so will improve some aspect of an industry or of life in general, depending on the project. And for almost all of these projects I want to work collaboratively with partners, anywhere from a loose open-source collaboration to jointly-owned companies.  And I will be able to be far more open and share my ideas on my blog unlike the past five-plus (5+) years as I won’t have the constraints on me that I was under while president, CEO, and fiduciary of Xtras.

So I am idealistic, but I am also pragmatic. This time I want to make sure my ventures are cumulatively far more profitable than Xtras was during my tenure. I’m not twelve years more experienced, and hopefully twelve years wiser. I want to accomplish my idealistic goals, not just dream about them. But I’ve learned the world does follow "The Golden Rule," just not the one they taught about in Sunday school. I’ve learned it is far better to be the one holding the gold otherwise you get stuck following someone else’s rules. :-)

For those of you who are interested, stay tuned to my RSS feed. I’ll be posting more about my upcoming adventures shortly.

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?