For the past 5-or-so years, Macs have been increasingly made to be more business-friendly. That is to say, more Microsoft-friendly, since Microsoft Windows Server software is such a dominant force in the user-facing server space (e-mail, remote access, file sharing, etc.).
The iPhone has been a challenge for us to get to work nicely with either of Microsoft's e-mail server juggernauts, Exchange 2003 or Exchange 2007. From synchronization issues to certificate complications, there just have not been a lot of full Exchange-on-iPhone integration projects that I would call "challenge free."
After the first generation of iPhone basically offered no support for synchronizing with Exchange, I welcomed the news that the second generation of iPhones would gain Exchange synch capability as a feature. It still wasn't perfect, but movement in the right direction nonetheless.
Today, I'm simply speechless at the news that iPhone OS 3.1 has gone the other way - it is less Exchange-friendly than before. Specifically, it no longer supports encryption that the default Exchange 2007 setup - and most corporate IT departments - require of mobile devices.
So, let me get this straight. Apple releases a "bug fix" 3.0-to-3.1 update to roll out an AppStore and ringtones enhancement, and breaks the corporate functionality of the software? Interesting priorities . . . some things don't change, I guess.
Tuesday, September 15, 2009
Monday, September 07, 2009
When Open Source is Less-open
As a guy who's all for more competition in the marketplace, the creative free-marketeering presented by the open source movement is a welcome one. Small businesses need to really be careful, though. When a company adopts an open source solution, what are they really getting themselves into? On the face of it, it seems like a win-win situation. It's a platform that is low- or no-cost, it can be enhanced and upgraded without copyright infringement worries, the company has a competent architect (presumably) to put it all in place and there is usually a fairly robust support community behind the technology. What could go wrong?
I've seen a few situations lately where companies have been talked into an open source solution whose upkeep and administration is a complete mystery to anyone other than the original implementation team (typically just one person). You can see where this goes: the implementer and the company part ways, and now the company's actually got a system that's more proprietary than if they'd just plunked down the money and bought a retail package.
Yes, there's a support community, but it's usually online-only . . . so the company still needs to find a specific resource willing to take on the task and unravel the Gordian Knot of their open source mess.
Money spent on mainstream solutions not only buys the software. It also usually buys the assurance that there is a healthy supply of actual human beings ready to work on the solution (not just an "online community"), and/or a company willing to step in and assist (for a fee, of course) with any need a company might have with their software.
Example 1: a company had been talked into converting one of their old file servers into an advanced Linux software firewall. It worked OK even when the Linux consultant left, but when they needed some more advanced VPN functionality they failed to find anyone who could make it do what they needed. The solution was to buy a $1,500 Juniper firewall and pay Foxtrot for a half-day of configuration time.
Example 2: a company had a Linux-based file server which was installed by a former employee. Nobody knew how or why it worked, and when it failed they had no idea what to do. They have a few people who are tech savvy enough to take care of some issues, but because none of their people are familiar with Linux, this problem was unsolvable for them. They asked us to come in and install a Windows Small Business Server, and now their people can at least have the familiar Windows desktop to deal with . . . and they've got Foxtrot and the rest of the Microsoft consultant community ready to fall back on.
I've seen a few situations lately where companies have been talked into an open source solution whose upkeep and administration is a complete mystery to anyone other than the original implementation team (typically just one person). You can see where this goes: the implementer and the company part ways, and now the company's actually got a system that's more proprietary than if they'd just plunked down the money and bought a retail package.
Yes, there's a support community, but it's usually online-only . . . so the company still needs to find a specific resource willing to take on the task and unravel the Gordian Knot of their open source mess.
Money spent on mainstream solutions not only buys the software. It also usually buys the assurance that there is a healthy supply of actual human beings ready to work on the solution (not just an "online community"), and/or a company willing to step in and assist (for a fee, of course) with any need a company might have with their software.
Example 1: a company had been talked into converting one of their old file servers into an advanced Linux software firewall. It worked OK even when the Linux consultant left, but when they needed some more advanced VPN functionality they failed to find anyone who could make it do what they needed. The solution was to buy a $1,500 Juniper firewall and pay Foxtrot for a half-day of configuration time.
Example 2: a company had a Linux-based file server which was installed by a former employee. Nobody knew how or why it worked, and when it failed they had no idea what to do. They have a few people who are tech savvy enough to take care of some issues, but because none of their people are familiar with Linux, this problem was unsolvable for them. They asked us to come in and install a Windows Small Business Server, and now their people can at least have the familiar Windows desktop to deal with . . . and they've got Foxtrot and the rest of the Microsoft consultant community ready to fall back on.
Subscribe to:
Posts (Atom)
