By Greg Wallace, Emu Software

Taxonomy: (from Greek taxis meaning arrangement or division and nomos meaning law) is the science of classification according to a pre-determined system, with the resulting catalog used to provide a conceptual framework for discussion, analysis, or information retrieval. In theory, the development of a good taxonomy takes into account the importance of separating elements of a group (taxon) into subgroups (taxa) that are mutually exclusive, unambiguous, and taken together, include all possibilities. In practice, a good taxonomy should be simple, easy to remember, and easy to use.

Why do I think a new taxonomy is needed for systems management? Type “systems management” (with parens) into Google and you get more than 58 million pages to sift through, with multiple pages of sponsored links from such companies/products as Sybase, OpManager, ConfigureSoft, MySQL, BMC, Perle, groundworkopensource, heroix, handysoft, Raritan and a slew of aggregation sites offering to help you make sense of all the different solutions. And though less numerous, the search results are no less varied when one uses any number of other more specific terms, like Configuration Management or Provisioning.

People in the industry know that the varied solutions offered by the above-listed companies perform different functions, that they do them in different ways, they act on different aspects of IT (devices, applications, etc), they are variously broad or narrow in scope and are designed to appeal to different audiences. Sure, all of them can be accurately described as Systems Management, but to someone trying to find a solution to a specific problem, this is about as useful as if I were to challenge you to name the living creature I’m thinking of and only give you the clue that it is a member of the kingdom animalia.

So, the sheer diversity of the search results and sponsored links highlights, I think, the need for a tighter framework to describe systems management functions and benefits so that users and solution providers (VARs, SIs, etc) can more easily identify the right solution to their and their customer’s needs. Let me say up front that I am clearly not the first person who has recognized the need for a more precise and standardized way of describing different types of systems management products (see, for example this Network world article). But I do think that the birth of OMC provides a new and great opportunity to actually achieve this objective. Why do I think this? Because I believe that one of the fundamental tenets of open source is transparency. As the only industry body explicitly focused on promoting open source systems management, one way the OMC can do this is by driving transparency around the way various types of systems management products are described.

If we think about why this problem is so bad, perhaps it comes down to the closed nature of traditional systems management solutions, and the effect this closed nature has on marketing habits. Like other proprietary IT solutions, traditional systems management solutions compete, in part, on comprehensiveness. The more the products do, and the more products offered (products that are frequently integrated together in some closed way) the more can be sold to installed base customers, and the less likely these customers will be to turn to another vendor. This is one mechanism of lock-in, and just as it is present in the operating system market, though less so now than say 5 years ago, so too is it present in systems management. And so it is understandable why proprietary systems management solutions may have a bias towards general, if accurate, descriptions – call it “fly in the web” marketing – the broader the web, the more flies one catches.

With open source projects, in contrast, our stuff can be downloaded and used by anyone and everyone, and so we must assume, regardless of the ambiguity of the terms we use to describe them, that the true nature of our product’s functionality, architecture, scope and benefits will become known in great detail, and rather quickly. Another salient difference is that we in the commercial open source community typically price on a subscription basis, which means that each year or two, our customers can vote to keep us, or kick us off their island, so we had better deliver what we promise. For these reasons, I would argue that OMC members ought to have a strong bias to be unambiguous in the description of our projects, using terms that place them in mutually exclusive sub-categories of the broader Systems Management main category. At the end of the day, it may well be, in fact it probably will be, the case that some projects are broader than others, but until we come up with a standard way of classifying systems management solutions, we have no transparent way to measure and express a product’s scope.

Step 1:

For starters, I’d love to get general agreement that the OMC will strive to set some standards for how member projects describe themselves. I, for one, like the way Webmin does it:

Webmin is a web-based interface for system administration for Unix. Using any browser that supports tables and forms (and Java for the File Manager module), you can setup user accounts, Apache, DNS, file sharing and so on.

Webmin consists of a simple web server, and a number of CGI programs which directly update system files like /etc/inetd.conf and /etc/passwd. The web server and all CGI programs are written in Perl version 5, and use no non-standard Perl modules.

This description has almost all the essential ingredients (missing, perhaps, is a quick statement of benefits). In these three sentences, it clearly states what Webmin is (a Web-based interface for system administration of Unix), what it does (you can setup user accounts, Apache, DNS, file sharing and so on. ), what it’s scope is (system administration for Unix), and how it works (Webmin consists of a simple web server, and a number of CGI programs which directly update system files like /etc/inetd.conf and /etc/passwd. The web server and all CGI programs are written in Perl version 5, and use no non-standard Perl modules.) I think this is a good formula, and could serve as a starting point for discussion around how OMC member projects can facilitate efficient “information retrieval” about our projects by standardizing the kind of information we provide in our project descriptions.

Step 2:

As with so much in life, any new systems management taxonomy would only be beneficial to the extent that people actually use it. And so I’d like to get a read from the other members of the OMC, and from visitors that may not yet be participants (you can join by going to: http://open-management.com/join/) as to whether they: A) agree that such a taxonomy is needed and, B) will commit to using it to describe their projects, assuming that we establish in advance the rules for discussing and deciding what the taxonomy would be. Only if a critical mass agrees that this is a problem and commits to using whatever we come up with do I think it makes sense to embark on discussing what this new taxonomy should look like.

From here, we can pursue more ambitious goals like agreeing on specific terms to describe certain capabilities and what the axes on which we measure projects’ capabilities should be. In the absence of such agreement and standardization, each of us will come up with our own way to describe our project’s functionality, scope, architecture and benefits, running the risk of using the same term to describe different things and different terms to describe the same thing. This serves no one’s interests, least of all the customer / user, and the solution provider that wants to find the best product or products to solve their customer’s specific problem(s). I hope others will agree that the OMC gives us an opportunity to achieve something that many smart people have recognized a need for but that, to date, nobody has really figured out how to accomplish.