Let's assume that Microsoft's prediction is correct, and that we will end up seeing 600 ISVs building and testing SharePoint 2010 solutions by the latter half of the decade. If, at the same time, these SharePoint shops build their capabilities in unified communications through growth or acquisition, the result would likely split the market. On the one hand, we'd have huge, full-service ISVs that support everything that is Microsoft. On the other hand, we'd see smaller, SharePoint-specific shops that are essentially legacy, point-solution providers. Over time, which group would you expect to be more successful? I'd bet on the big guys.
There's nothing necessarily wrong with doing business with a big software company or a big ISV that's going to have strong incentives to find ways to improve your business on multiple fronts, from productivity to collaboration to communications. You'll just want to go into such an arrangement with your eyes open.
What's the alternative? There are certainly other technologies that can compete with the Microsoft stack at each level, and I'll explore some of those technologies in future articles for InformationWeek SMB.
Microsoft has traditionally done well at attracting developers to its programming environments through a combination of low-cost training, guaranteed marketing support, and the promise of large addressable markets. This environment attracts professional IT services firms, which as described earlier, are likely to expand in scope to match the growth in the Microsoft product set.
Open source technologies, such as Drupal or Joomla for content management and websites, or Asterisk for telephony, involve a different value proposition for both developers and their clients. For many SMBs, not having to write a check for user licenses is a badge of honor. And for developers of a certain mindset, the attraction of an open, elegant, and customizable codebase should not be underestimated. As a result, a small team of talented programmers can build with open source tools systems that rival the most high-end commercial software.
Combining the two approaches, we see firms such as Oracle and IBM that combine open source technologies with proprietary offerings, accessed through highly developed professional services organizations and vertically focused partner networks.
The decision probably comes down to how well you can match the expected duration of your project with the resources that you can hire or retain. If your SMB is taking a big chance on a new service that will either succeed wildly or fail quickly, you might put the ball in the hands of a highly motivated open source advocate with access to the latest and greatest tools. However, if you're trying to build a system that you expect will persist from generation to generation, you may want to build on an architecture that has the highest likelihood of persisting from one generation of programmers to the next.
Regardless of the technology, the most important question is who's going to install, build, maintain, and upgrade it. Ultimately, technology decisions are about the people who will be responsible for maintaining that technology. The "who" is vastly more important than the "what."