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.
Readers of my prior posts about the "My" Classes planned for VB 2005 know that I am pretty enamored with them: here, here, and here. I think the "My" classes have the potential to become one of the most significant productivity features of VB 2005 and beyond, and could result in a huge reduction in development complexity.
However I recently read several articles about extending the "My" namespace that have me extremely concerned. The first was by Anand whose article was entitled "Extending the "My" Namespace." Both The Microsoft VB Team’s Paul Vick and TheServerSide.NET’s Ted Neward picked up on Anand’s article here and here, respectively.
The second article was by Keith Franklin entitled "Oh My!! - A Look at the My Namespace in Visual Basic 2005" in Code-Magazine’s Sept/Oct 2004 issue. Though don’t quote me, I also seem to remember Mike Sax talking to me about how he would like to extend the "My" namespace with serial communication functionality.
(Note: I deliberately use the terms "classes" and "namespace" interchangably because because "My" encompasses both classes and a namespace, and because collectively others have used both terms.)
I definitely respect the writing and development skills of both the authors of the two articles I quoted, and I think they did an excellent job of explaining in technical terms how to extend the "My" namespace. I also respect Mike Sax’s ideas and opinions very highly too. So please don’t take this as a criticsm of them or their articles or ideas. Instead just take it for face value.
So after reading those articles, you’ll now know how to extend the "My" classes in VB 2005. However, just because you can extend the "My" namespace doesn’t mean you should!
I’ll go ahead and give the benefit of the doubt to everyone else as it is possible the problems caused by extending the "My" classes are not be immediately obvious. Maybe the past 10 years running the leading reseller of components for Microsoft-centric developers (via VBxtras and Xtras.Net) has given me specific insight into this issue that others without similar experience would be hard pressed to have.
As a way to explain why extending "My" would be a bad idea, let me anticipate for you both a positive and a negitive future, five years hence. In the positive future:
It’s 2010 and Microsoft has released two more versions of VB since VB 2005. Microsoft released "VB Revolutions" in late 2009 ("VB, Reloaded" was previously released in mid 2007.) VB now contains almost every bit of needed functionality used 80+ percent of the time wrapped up in an incredibly intuitive class/object hierarchy.
Collectively VB developers are still not quite as skilled as their C# brethren. However, as a group they have increased their productivity compared to their C# brethren by literally an order of magnitude. VB developers now garner 50% higher wages than C# developers simply because of the incredible productivity difference (A small group of C# developers lobbied for adding "My" to C# however more than 75% of active C# developers successfully defeated this potential inclusion by convincing the Microsoft C# team they didn’t need a "dumbed-down" programming language.)
Further, the third party component market is booming. Unlike the early days of .NET, most VB developers now embrace the use of third party components, and most of those components are accessed via the "My" classes. The reason VB developers are so collectively positive about third party components now are 1.) the entry costs have been brought down and 2.) the risk of using third party components has been almost completely removed, unlike five or more years ago. Now every different type of component implements a defacto standard interface, and there are many components implementing each widely used interface.
For example, one of the earliest interfaces was the IZip interface. Any component that implements the IZip interface can be specified in the app’s app.config file as a "provider," and any use of My.Files.Zip in code would use the specified provider:
<add interface="IZip" type="MyTools.Zip, Tools" />
You see Microsoft decided before releasing VB 2005 way back when they had to lock down the ability to extend the "My" classes so it was only possible for Microsoft, or someone with Microsoft’s blessing, to extend them. Had they not done so, they knew all hell would have broken loose(see my negative future below for this alternative.).
Though Microsoft decided to lock down the "My" classes they did offer an alternative. Taking a page out of their own play book and empowering developers to use it, Microsoft made it possible for developers to "embrace and extend" the "My" classes by creating their own class that could psuedo-inherit a copy of the "My" classes, and then extend them:
Embrace "My" As Xtras."My"
Console.WriteLine( "CurDir: " & Xtras."My."Application.CurrentDirectory )
Embrace "My" As Xtras
Console.WriteLine( "CurDir: " & Xtras.Application.CurrentDirectory )
Once a developer "Embraces" the "My" namespace, they can "Extend" it in any manner they wanted.
Of course Embracing and Extending wasn’t Microsoft’s only plan for the "My" class, but it silenced the would-be complainers who were chomping at the bit to extend "My."
Microsoft’s next "My" step was to sponsor an open-source project. They engaged a third party component specialist from outside the company to manage the process, and they provided funding to ensure the project maintained its priority.
They called this project "My", Reloaded" as a pun on the Martix movie trilogy, and that is of course how VB9 later got named "VB, Reloaded." At first they hosted MyR on GotDotNet until GDN was finally taken down do to a massive crash which lost all source code (fortunately most GDN source was available from individual developers), and then Microsoft started hosting MyR on SourceForge as well as all sponsoring a GDN-replacement space on SourceForge (Interestingly, Microsoft invested $50 million in SourceForge only 6 months after the switchover. But then that’s another story…)
They started the MyR project by engaging the .NET developer community, especially third party components vendors to propose extensions to the "My" namespace. They used the .NET Wiki tool called FlexWiki created as a side project by then Windows Program manager David Ornstein to ensure it was as open and friction free as possible. For any proposed extensions that had enough outside interest, the MyR project manager elevated the extension to "Acknowledged."
Once "Acknowledged", the MyR project manager informed the appropriate members of Microsoft’s internal VB team and engaged community members interested in the extension to collaborate until they all agreed upon the exact interface that would be used to extend the "My" classes. At that point, and only then, the extension became an "Approved" extension.
Once approved, a member of the Microsoft VB team used private/public key encryption to "sign" the "Approved" extension interface so the .NET framework could recognize it, and they released a small patch for the .NET framework that anyone using the extension would need to apply. Microsoft also modified the .NET framework to apply that patch itself over the Internet, assuming the user agreed and had the appropriate code access security. (Actually I’m not sure of the details on this one. It is possible they just including the patch in Windows Update, or maybe that was the early talk and they found a way to avoid patching the framework to recognize approved extensions. Whatever the case, it works and doesn’t cause problems.)
Interestingly, when the MyR concept was first announced, almost all of the larger third party vendors were tentative. Once the "Approved" extensions started to trickle out, open source developers started to create free versions of these components and then came the huge outcry from those same large third party component vendors. Most of those with lower-level easy-to-implement components went out of business, but they complained loudly about how Microsoft had screwed them as they were going down.
Then an interesting thing happened. Saavy 3rd party vendors started innovating on top of the approved "My" extensions. Developers had to cast to use the innovations, but that was fine. Most of these vendors sales went through the roof! Developers started buying more components than before because the standarization gave them the confidence to incorporate more external components into their apps, and because they wanted the vendor support they didn’t get from open source.
Still other new vendors came along and started offering tech support for the open source components, ala RedHat. Their businesses thrived! All in all, by the release of VB Revolutions, 3rd party component usage grew among developers from around 20% in 2005 to over 80% of developers in 2010. And those developers purchased and actually used a lot more components. Because they could depend on them.
Oh, a few more things.
The next version of C# scheduled for 2011 plans to incorporate the "My" classes. Microsoft’s C# team decided to heck with the zealots amongst C# developers; they’d get "My" classes anyway, and they would be happy they did (or else C# might disappear.)
Also, Java usage is way down now, to less than 5%. Even though five years ago everyone believed that .NET and Java would be a close #1 and #2 instead what happened was it .NET/Win and .NET/Else (i.e. Mono) became #1 and #2. Funny how things change. :)
And now for the bleak version:
It’s 2010 and things have been very discouraging over the past five years.
Microsoft has managed to release only one new version of VB since they released VB 2005 to much fanfare. This more recent version came out in 2008 and was called "VB, Finally!"
Microsoft released two versions or C# in the same time, but VB was in such disarray they had to skip a VB release, and man did that add fuel to the C# developers fire! "Real Programmers use a language with a future!" was all VB loyalists heard from the C# contingent. The name of the last VB was particularly ironic because it just may be the final version Microsoft releases. There sure is a lot of buzz to that effect.
Back just before VB 2005 was released, everyone thought things were going to be great for VB, what with the "My" classes they were promoting as an almost panacea for simplifing VB development and improving VB developer productivity. Boy was that not the case!
I think the problems all started with the fact Microsoft allowed the "My" classes to be extended. Just like the DotCom euphoria (don’t people ever learn?), VB developers of the day jumped on "My" classes and started putting ever utility function they could thing of into "My." And it worked great. In the begining.
By extending "My", the "tool" builders on development teams were able to create their own extensions to "My" which brought them the same huge benefits for their own internal development framework that all VB 2005 developers were seeing with "My." Productivity was increasing significantly.
Then after about three months, a trickle of third party component vendors started releasing new components that adding to the "My" classes. This too made it easier for developers to learn and understand third party components. By six months after VB 2005’s release, practically ever third party component had a "My" extension. All seemed wonderful. Kind of like the world felt on Sept 10th, 2001. (Well heck, maybe more like April 2nd, 2000, the day before Judge Thomas Penfield Jackson ruled against Microsoft which triggered the DotCom crash…)
Then things started to unravel. At first it wasn’t so bad. Developers would choose two component they needed, but those used different names for the same concept: Mike Sax’s Sax.Net used "My.Communications" and another vendor used "My.Comm." Not a biggie, but confusing.
But as the months went by, the proverbial shit hit the fan. Vendors were using the same names in their extensions that other vendors were using, but they were not compatible. And it got worse, developers had so extended "My" that very few third party components could be used without conflicting with the developer’s own pre-written frameworks.
In short order, corporate developers started missing milestones left and right. They were finding it impossible to integrate the third party components on which their project timelines depended.
Next came a backlash against third party components. A few blogging firebrands blamed third party vendors while conveniently ignoring the fact it was instead Microsoft who has inadvertently laid a huge trap for all VB developers.
Of course this caused sales of third party components to literally grind to a halt. The lucky 35% were able to move to some other software or related business such as consulting. Unfortunately the remaining 65% of third party component vendors went bankrupt within a one year period.
Whatever the case, the tech media smelled blood so started sniffing around, with C|Net in the lead. They interviewed VB developers and third party components vendors, and to a statement printed everything negative and nothing positive. This caused a tidal wave of fear among development managers and their bosses, and .NET projects all over were canceled.
At first it was just VB projects, but then it also included C# and soon anything .NET because managers were either confused and didn’t understand it was a VB.NET problem (except for the third party components that might be used in C# apps, or course), or they just became wary of any development tool from Microsoft.
Soon VB developers started filling the jobless ranks quickly followed by C# developers. Not all lost their jobs, but not everyone could learn other technologies quickly enough to switch. But more importantly, with the civilized world having become so dependant on computers, this caused us to slide into a horrible worldwide recession, almost bordering on a depression.
Then in 2006, sensing opportunity, Novell released Latte which was a new language with the flavor of VB but instead supporting the Java VM. Latte was based on the core code of Mono. Borland, not one to be loyal to any one platform, created Latte Builder by leveraging Eclipse, and it was universally agreed to be the best IDE around for Latte. RedHat then bought Borland and Borland became RedHat’s developer division.
Former VB developers started learning Latte en masse, or at least those who didn’t have to take two menial jobs just to keep food on table. Some former C# developers even chose Latte because it didn’t have any "basic" baggage, but most C# developers moved to Java.
IBM, sensing opportunity, invested $10 billion. Some of that money went to prop up Novell whose Zimian Mono team had converted their code to support Latte and needed an infusion. Another recipient was RedHat because IBM wanted to see two strong Linux players and wanted to ensure Linux/Latte would never be challenged by Windows/VB again.
IBM also used some of that $10 billion to purchase numerous application software companies. Those with .NET apps were given marching orders to rewrite in Java or Latte, move their clients over, and then drop their .NET versions. In what appeared to be an amazing blink of an eye but was really two years, IBM had a full suite of software on Linux to rival Microsoft’s front and back office solutions including their own commercial version of OpenOffice.
Back around 2006 Dell started pushing Linux really hard, and by the time IBM had completed its Linux suite of applications, Dell announce it would no longer ship Windows on any of its computers by default; you would have to special order it. Dell shipped all new PCs with either RedHat or Novell Linux.
Clearly Microsoft’s revenues went into a tailspin. By 2009 MS had become one tenth of its former size selling legacy systems to late majority customers and laggards with no R&D budget, all in the period of just a few years.
Although I’m sure it was just urban legend, Bill Gates reportedly had to mortage his Lake Washington home to cover payroll one month. Pundits claim that is when Melinda filed for divorce followed by a bitter child custody battle which is still raging on today, and the news media is having a field day with it.
Finally, in late 2009 something really tragic thing happened. Software written in .NET for the air traffic control system malfunctioned because of a "My" class conflict that occurred in a dynamically loaded module. That malfunction caused a huge fully loaded Etihad Airways Airbus A380 with 574 passengers and crew aboard to crash midair with an Air France Boeing 747 Advanced carrying 512 passengers and crew (Etihad is the national airline of the United Arab Emirates.)
The crash occurred directly over UN Headquarter in New York, and the UN Headquarters was demolished when the two planes fell on it. The debris covered a radius of 1.37 miles and killed a total of 6247 people, 5291 of which were Americans…
Funny. Just five years ago life didn’t seem so grim. :(
See what I mean? Extending the "My" classes is a real no-no!
Okay, so both scenarios are a bit extreme. Please don’t post comments about how items that were technical impossible or statistically unlikely. I know that. I wasn’t trying to document perfection. I was trying to paint a picture, and I wanted one to be as rosy as possible and the other to be totally grim just as did George Orwell with his famous work "1984." Actually, I hadn’t expected to write such long scenarious but once I got started I just couldn’t stop! :-) I actually had tons of fun writing them.
I had planned to follow the scenarios with specific arguments and a summary, but after writing them I think the scenarious speak for themselves. I just hope Microsoft is listening. If Microsoft doesn’t listen, its up to all VB developers and third party vendors to keep the second scenario from becoming reality. :-)
P.S. For the record, I think the first scenario has a lot more potential to transpire as described because of actions related to the "My" classes than the latter. Especially the last paragraph of the latter!
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.
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?
Mike Sax mentions my blog today on his blog.
However, Mike talks about Component Resellers and, by asking:
“How component and tools resellers can re-invent themselves to provide value for developers?”
he implies component resellers don’t currently offer value to developers, kind of like the old trick question:
“So have you quit beating your wife?”
Mike states that in the years before the Internet vendors needed our printed VBxtras catalog but says they don’t anymore because:
“The Internet has challenged the value resellers used to provide. Finding the right vendor is only a Google or Yahoo search away. And if you want even sharper focus, you can just browse some of the component galleries out there, like on ASP.NET”
(One question to Mike; have you actually ever tried to use the component galleries on ASP.NET? It’s a hodge-podge and very difficult to use as we use it to try and find new vendors. Even my competitors do a much better job.)
So let me address his implication that resellers don’t provide value:
- For those who care about price, we always offer lower prices than vendors. If developers are on a tight budget or buying for a lot of developers, they can almost always save money buying from a reseller like VBxtras and Xtras.Net.
- For developers buying for a large number of developers and/or products from multiple vendors, they can aggregate purchasing.
- If developers purchase on Net 30 accounts, they can establish the Net 30 accounts with us once instead of once per vendor,
- If they buy from us at least, all their downloadable software purchases and all their serial numbers will be held in their “online library” at our website for future reference. No need tracking down the vendor when the bits are lost or the serial numbers are misplaced.
- When developers buy direct from a vendor and they have problems the vendor won’t correct, they have no advocate. The developer is just one of probably tens of thousands of other developers whose complaints are lost in the noise (I have emails from developers who didn’t buy from us but wish they had because of this. I could post but don’t want to as it could get real ugly with those specific vendors…) If they buy from us and have a problem, we’ll go to bat for the developer. After all, there are not that many resellers, and as resellers we are much more focused on customer service than the average vendor. (If our customer service sucks, why would a customer buy from us? If the vendor’s customer service sucks but his product is the best, developers still grudgingly buy.)
- If a developer buys direct, who is going to help them select amongst competitive products? A vendor will rarely tell a customer his competitor’s product are much better for their needs, especially if that vendor’s sales people are commission-based. Since we carry multiple products in a category, we can help developers who need help selecting products to decide what best meets their needs, especially since we are the most focused reseller amongst our competitors (Focus: VBxtras = VB6/ActiveX only, and Xtras.Net = .NET only).
- Though I can’t speak about other resellers, one of the benefits of buying from us is our new XDN program, short for Xtras.Net Developer Network. We have three levels: Basic, Plus, and Professional (actually Plus hasn’t been finalized as I blog but will be soon.) We position XDN as “Empowering Serious .NET Developers” and our Professional membership ($99/year) has some pretty outrageous benefits, we think. XDN targets those developers that are influencers amongst their peers, especially the ones that evaluate and buy and/or would like to buy a lot of 3rd party products. How is this a benefit of buying from us? Starting this month we give developers 10% of their purchase price (5% on Microsoft products) toward an XDN Plus ($25) or an XDN Professional ($99) annual membership. We plan to expand that concept over the coming months. The choice seems clear to me: pay full price at vendor’s site with no additional benefits, or pay a discount at VBxtras or Xtras.Net and get a lot more benefit than just the one product.
These are just some of the reasons why I believe component vendors still add great value today. I’ll blog about more reasons in the future.
However, I will say that we are having challenges. Our two biggest challenges:
- How we can stay top-of-mind? How do we get the developer to remember to come to us instead of just going to Google? (This isn’t really that hard for us to solve, and we are hard at work on it right now.)
- Much worse, how do we get past Corporate Resellers? What are Corporate Resellers? They are the general resellers that large companies contract with to manage all their software purchases. These corporate resellers typically offer zero value to vendors and developers yet are gaining an increasingly large share of purchases as Windows development becomes more enterprise critical. It is almost impossible for us to compete with these corporate resellers. We go to trade shows and developers tell us “We love your catalog and website. We download demos all the time!” When we ask if they buy from us they say “No, we have to purchase everything through our corporate reseller” and they typically don’t seem to care to help us and try to get around that requirement. Grrr! It makes me want to limit my website and downloads to only people who can buy from us if they decide to make a purchase!
On the other hand, like so many other companies that have been affected by the Internet, we are evolving, and “How?” was what Mike Sax’s asked in his blog. In two to three years, we’ll probably look very different than today, offering lots of new services. I don’t think that means we’ll stop being a component reseller; on the contrary I think we’ll become far stronger as a as we evolve and add these services.
So how will we evolve, and to what? Only time will reveal. :)