To customize or not to customize?

Earlier this week I had the opportunity to talk at the Microsoft VBA Technical Partner Summit.  We basically hosted about 100+ Visual Basic for Application ISV partners (some on-site and some online who participated through Microsoft Live Meeting).  Some of these partners were participating from Europe and it was interesting to see that late into the evening in Redmond (must have been the wee hours in Europe), some of these partners were still actively participating.  It reinforced my belief in a healthy VBA ecosystem.


I am a huge believer in the support and success of our partners as a key element of Microsoft success.  In the specific area of application customization, it is no different.  VBA was first introduced in partner applications 7 years ago after it had been added to Office applications over two previous releases.  It quickly was adopted by the industry and today there are over 300 active VBA partners.  A couple of success stories here include the 2nd largest ISV in France that provides software to 60% of the Aerospace market, the #2 manufacturer of process control software that uses VBA-enabled solution for power plant automation, not to mention Office J.    


I personally like this area because it’s a four way win.  End users, developers, partners and Microsoft all have gained from the flexibility provided by application customization.  In the coming years Microsoft is going to continue to invest in application customization technology and will continue to work closely with our partners to make sure we advance the technology.



Comments (2)

  1. Why does it ‘have’ to be VB? Why can’t it simply be a customization layer? netFx is there. The devenv shell is used. It doesn’t seem like that much of a leap to allow C# or any managed language to play in the space.

  2. Soma says:

    Paul – you are right. It doesn’t have to "VB" in the new world. Any "managed code" language should be doable in this space. – soma

Skip to main content