Despite pleas from its developers, Microsoft is ending free support for Visual Basic 6 this month.For the open source community, this is no great loss. Actually, it's not even a blip on the radar -- open source developers will continue to chug along, writing code in Perl, Python, PHP, Ruby and other languages that belong to the communities that use them.
But Microsoft developers have a lot invested in VB6. Companies, foolishly buying in to the argument that buying Microsoft equals stability and support, have spent a lot of money on projects developed in VB6. Microsoft is trying to paint this as inevitable progress, but the fact is that Microsoft simply wants to kill off VB and move developers to Visual Basic.Net whether they want to go or not. Developers versed in VB6 now have a new, or at least very different, language to learn, and organizations now have a bunch of obsolete code that won't carry forward. From where I'm sitting, that makes VB6 (in retrospect) a pretty poor investment, and it should provide a cautionary tale for anyone thinking of jumping from VB6 to the VB.Net bus.
The fact that the language has changed isn't, in itself, a bad thing. Python, Perl, Ruby and PHP have all changed as they've matured, and will continue to do so. Perl 6, when it's finished, will be quite a bit different than Perl 5. The difference here is that no one company or organization has complete control over the source or direction of any of those languages. No one can force Perl 5 developers to move to Perl 6, and if the community decides that Perl 6 isn't what they want, they can take the source for Perl 5 and keep it going as long as they please.
If the legions of VB6 developers had access to the source, they could pick up VB6 and carry it on their own shoulders, much as the supporters of the Mozilla Application Suite are doing now that the Mozilla Foundation has decided to discontinue development of "Seamonkey." But they do not, so they're forced to dance to Microsoft's tune.
VB.Net may be much better than VB6, but it's going to present significant pain to developers and organizations that have to adapt to the new language. Perhaps as some of the development teams meet to hash out their strategy for new projects, they'll think about picking a technology they have a little more control over -- or face doing it all over again in a few years, when Microsoft decides to transition from VB.Net to whatever its successor will be.