A couple of weeks ago, I took BEA to task for insinuating that the open source community wasn’t capable of delivering good management tools for its software. A few readers leapt to the defense: BEA is right, they said. Management is critical in complex environments, and the management capabilities of open source software are often pretty poor.
Maybe so. But if that’s true, it’s all the more reason to make some noise about it and get open source developers more interested in delivering those tools. Because the alternative — turning to proprietary software for the management piece — could have fairly unpalatable side effects.
By way of example, let’s take a look at another closed-source tool that can manage open source software. Vintela Authentication Services, part of Quest Software’s suite of identity management products, makes it easy for network administrators to centrally manage user access accounts on Linux systems. And, I must admit, I’ve seldom felt as conflicted about an IT product before.
The reasoning goes that most IT organizations have two types of administrative staffers. The Windows admins are accustomed to the day-to-day maintenance of Windows networks, including end-user support for desktop workstations. Linux admins, on the other hand, tend to be a more rarified breed. They have different core knowledge and experience — not to mention being more expensive.
When employees join or leave an organization, however, provisioning their physical workstations is usually only one of the IT tasks involved. They also inevitably need access to a whole variety of servers, including mail servers, in-house Java applications, even databases. Many of those servers are maintained by the Linux side of the IT organization, yet adding and deleting user accounts is seldom the favorite part of those admins’ jobs. More importantly, it’s also probably not the best use of their time (dollars, again).
This is where Quest comes in. Vintela Authentication Services, in conjunction with Quest’s other identity management products, makes it possible to manage those Linux user accounts through Active Directory and Microsoft Identity Integration Server. It allows Windows admins to automate and maintain central control of these functions, freeing the Linux admins to concentrate on more critical systems maintenance tasks. What’s more, centralizing in this way makes it easier for IT to deliver audits of account creation and deletion, for compliance purposes.
Personally, I think this is brilliant. It eliminates bottlenecks and reduces IT drudgery, and does so in a sane way using proven tools. I’m sure that many admins on mixed Windows/Linux networks will be thrilled to discover it. But there’s a more troubling side to it, too.
“We take the essence of Samba and apply that to identity management,” Jackson Shaw, senior director of product management for Quest’s Active Directory products, told me in a recent meeting. “We don’t use Samba, but that’s the idea.”
And there’s the rub. Quest doesn’t use Samba because it doesn’t have to. Quest has a close partnership with Microsoft, so it doesn’t have to reverse engineer Microsoft protocols the way Samba does. In fact, Microsoft encouraged Quest to acquire the former Vintela in 2005, after investing US$10 million of its own in the company.
Why would Microsoft be so interested in a company that provides management tools for Linux? Consider the ramifications.
By encouraging a policy in which all identity management and account provisioning happens via Active Directory, Quest’s products effectively make Linux servers subservient to the Windows infrastructure. They also effectively elevate the Windows admins to become the gatekeepers of those Linux resources. In other words, they keep Linux right were Microsoft wants it: at the back of the server room, out of sight.
Are you willing to make that compromise? Some will be. But to others, this kind of solution represents the worst kind of vendor lock-in.
Which brings us back again to the topic of open source management tools. Should we really manage open source software with tools and protocols that are closed and proprietary? One could argue that this is, in fact, the last place you’d want to use a proprietary solution. So if open, standards-based alternatives truly don’t exist, I don’t see that as a failure of the open source community. Rather, it’s a tremendous opportunity.