The Outlook ISV Community

You know you’re passionate about a subject when a conversation you expected to last 15 minutes is still going after 45 minutes and could go on all day. The subject? Outlook independent software vendors (ISVs).

The recent sales of two Outlook ISV firms have put the subject in the news. Microsoft has purchased Lookout Software, maker of Lookout, a highly regarded Outlook- and file-search program that’s now available as a free download on the Microsoft Download Center (http://www.microsoft.com/downloads/details.aspx?FamilyID=09b835ee-16e5-4961-91b8-2200ba31ea37&DisplayLang=en). You Software purchased Sperry Software, developer of more than two dozen Outlook add-ins used by more than 12,000 users. Both Lookout Software and Sperry Software were prominent ISVs that produced highly focused Outlook add-ins with specific features that users want. Many Outlook ISVs are small companies or single developers whose handful of add-ins helps advertise their ability to do custom Outlook programming; others are large software firms, such as the makers of PDA synchronization, antispam, and antivirus software. However, organizations whose power users, administrators, and programmers use Outlook to increase productivity within the organization by automating key business tasks, often at the departmental level, can also be counted as ISVs. These "corporate" ISVs aren’t "vendors” who sell their Outlook add-ins or give them away as promotional tools, but the groups have everything else in common.

How does Microsoft see these groups? Microsoft’s relationship with the big Outlook ISVs is already strong, but the small commercial ISVs don’t have a dedicated communications channel with Microsoft unless they meet the requirements and pay the fee to become a Microsoft Certified Partner. That leaves out the single-person shops and definitely puts the corporate ISVs off the radar. As a result, I don’t think Microsoft understands the breadth of Outlook development going on today--neither the skill levels of the developers nor the fascinating variety of their applications.

That passionate conversation I mentioned earlier included a debate about what it might take to make Outlook as popular an applications platform in 5 years as Microsoft Word and Excel are today. I know of at least four significant hurdles. First, Outlook--unlike Word and Excel--isn't document-centric, nor is it a relational database, so even experienced Word, Excel, and Microsoft Access developers who want to automate Outlook might have trouble knowing where to begin. Second, the Outlook object model is incomplete, so even the most basic application can require the developer to become fluent in other Outlook-related programming libraries such as Collaboration Data Objects (CDO) 1.21 or the third-party Outlook Redemption library. Third, there are a vast number of undocumented “gotchas” that require a certain amount of fussy code or that just can’t be done in Outlook. (Particularly frustrating are the techniques that are available in the UI but have no programmatic equivalent, such as setting the text labels for calendar color-coding.) Fourth, for ISVs that target the broad spectrum of Outlook users, the testing burden is huge. Even if you wanted to develop for Microsoft Office Outlook 2003 only, you’d need to test three different mail profiles: one each for Cached Exchange Mode, classic Exchange Server, and non-Exchange configurations. To do the job right, you’d also want to test on different OSs and against both the original Outlook 2003 and the recently released Service Pack 1 (SP1). In this regard, corporate Outlook developers have it easy because they can usually count on a standard desktop configuration. Still, they need to stay alert for hotfixes and service packs that might affect their applications. For example, Office 2003 SP1 added automatic signatures to custom form messages, taking some developers by surprise.

So where do Outlook ISVs--especially those midsized and corporate ISVs--come in? Take the Outlook gotchas. These quirks might be undocumented, but they aren't necessarily unknown; descriptions of most of them exist in books, on Web sites aimed at Outlook developers, or in public discussion forums, often with suggestions for workarounds. This ad hoc body of documentation has helped build a strong international community of Outlook developers who enjoy a sense of shared relief when someone devises a solution to a thorny problem so that everyone can stop banging their heads against the wall.

Microsoft’s distance from the bulk of these Outlook ISVs puts it at a disadvantage when it comes to gauging the need for new features and practical documentation that address the real-world needs of Outlook programmers. I asked some longtime Outlook developers about their concerns and got an earful about the antiquated forms engine, inadequate documentation, and a tendency to introduce new programmability features (e.g., Smart Tags) instead of fixing the deeper concerns in the basic Outlook development platform.

Microsoft’s attitude toward Outlook ISVs might be changing, though. The online Office Marketplace now offers a place for even small developer operations to spread the word about their applications. MSDN Web site managers took the time to reach out to Outlook developers, both at this year's MVP Summit and at Microsoft TechEd. Also at TechEd, Microsoft invited Outlook developers to a focus group to hear about some possibilities for the next versions of Outlook and to provide feedback about top Outlook programmability issues. Most telling might be another important Microsoft acquisition. Earlier this year, the company hired Randy Byrne, cofounder of Micro Eye (a successful Outlook ISV) and author of “Building Applications with Microsoft Outlook Version 2002” (Microsoft Press), to work as a program manager for Outlook programmability issues. Stay tuned--it seems that this conversation isn't over yet!