Guest Opinion

Support Classic VB

Microsoft's support for VB6 expires at the end of this March. Karl Peterson explains why he is behind a petition to extend support for the product.

• By Karl E. Peterson
• 05/01/2005

A group of MVPs, frustrated that Microsoft plans to end mainline (unpaid) support for VB6 on March 31, initiated an online petition recently that asks Microsoft to extend ongoing support of Classic VB (aka VB.COM). In short, the petition asks that Microsoft incorporate VB.COM into the current Visual Studio product line. This suggestion is in the best interests of both Microsoft and its long-term customers.

The main goal of the petition is to encourage Microsoft to extend support significantly for Classic VB. There are millions of existing VB6 and VBA applications; this alone constitutes a compelling reason to ensure support for these applications on existing platforms. Otherwise, the authors of these applications have no means to use new platform features and no reason to encourage their customers to adopt the new Microsoft platforms. Rather, concern about the compatibility of VB6 on these platforms will encourage them to keep their customers on old platforms, costing Microsoft both momentum and upgrade revenues.

Given this, Microsoft has every reason to offer both VB.COM and VB.NET products. Yes, it would cost Microsoft money to develop a new version of VB.COM, but this is more than offset by income from Microsoft's real profit center: its Windows platforms and servers. Losing the rich client market to Web apps is losing the lock-in.

Incorporating VB.COM into Visual Studio opens the world of .NET to legions of Classic VB developers. Many VB.COM developers don't even have VS.NET installed, as things stand now, so they aren't experimenting at all with the new opportunities it offers. Offering support for Classic VB in the new IDE would encourage them to load up VB.NET and start poking around. The most likely outcome would be new .NET solutions developed side by side with maintenance of their older COM applications, and increasing doses of interop tossed in for excitement.

There is precedent for this kind of approach. Microsoft has always bent over backwards to avoid abandoning customer assets. Its history is one of moving data forward. In fact, it has offered both forward and backward compatibility with nearly every other major application upgrade it's offered. Declaring customer data to be disposable is an extremely dangerous precedent. This time, "only" 6 million (its number) of its customers were affected.

Simply put, most well-written business logic code is platform-independent. For instance, the fundamentals of a QuickSort algorithm have been in place for decades, and there is no plausible excuse for Microsoft to force such code to be rewritten as the price for compiling in the latest product. Wholesale application rewrites are rarely advisable, as Joel Spolsky once noted. When the time for a rewrite comes, it must be at the developer's discretion, not dictated by the tool vendor. (Everyone agrees the migration wizard isn't a viable option, for countless reasons, right?)

According to a recent (unscientific) survey conducted by Visual Expert, nearly 80 percent of developers still use Classic VB, eschewing the .NET platform as they maintain their legacy code base. This should be a worrying number for Microsoft. It's also unfortunate because Microsoft could have avoided this situation by allowing Classic VB developers to bring their applications and their customers along for the ride at the time VB.NET debuted. These customers are now (predictably) exploring alternative programming platforms that offer either a long history of language stability (i.e., Delphi), or more open standards and wider vendor and platform support.

Consider, for a moment, the effect of bringing VS.NET into a business that has invested heavily in Classic VB code. Many shops won't see this as an option, given the burdensome cost of rewriting their core operational code. But dropping VB6 into the .NET IDE puts VB.NET into these shops by default. Indeed, this strategy harkens back to the guerilla marketing employed originally to bring VB1-3 into the office, when small-scale solutions grew into mission-critical apps in short order. Leaping the cost-to-rewrite barrier to get to initial acceptance would facilitate more widespread adoption of the .NET platform.

You can read the petition urging extended support for VB6 at http://classicvb.org. I urge you to sign it. It asks only that Microsoft support its customers in the same way you're trying to support your customers. If Microsoft takes the suggestion offered, it wins from the influx of developers to the new platform. Not insignificantly, early adopters of VB.NET would also gain the reassurance that they will not see their own investment rendered disposable with the next platform shift. And of course, Classic VB users win with another chance to move forward. Win-win-win.

The opinions expressed in this editorial are those of the author and not necessarily the opinions of VSM.