After persistent media rumours of an Oracle-based GNU/Linux distribution, Mr. Ellison finally announced it. Sort of. It’s offering Oracle support services around the Red Hat Linux distribution. It makes sense–I think companies need to make the entire life of the software solutions they sell a seamless continuum lacking problems and time-wasting intervention from their customers. Yet, a lot of people are writing about how this is a move to hijack Red Hat’s support business or is a forking maneuver. Some are saying it’s a warning to Red Hat, which is true, but I think the warning does not come in the sense of a support business hijack or fork. Oracle must have a more comprehensive picture in mind. Rather, I think Oracle’s move makes sense in order to steer its solutions into a comprehensive and lean offering. So I’ll explain why the fork doesn’t matter and why the support services on their own aren’t the real threat.

I refer to an idea I put forward some time ago for what needs to happen with the Linux desktop to catapult it to widespread adoption. I was asserting that there needs to be a Linux vendor changing the entire OS market game by offering: A full computing solution should come from a company that pre-bundles everything its customers want, consistently supporting it, for the duration of ownership. It should not require anxious intervention from the owner when the owner desires a new component or new system, and the new system should have all data and applications from the old system installed, setup, and accessible upon delivery. I would expect this to apply just as well to business software systems as individual user systems. I further believe that such a solution is only possible to fulfill, in all its complete glory, within a FOSS ecosystem (read that idea link at the beginning of this paragraph for details on why). This latter point can play to Red Hat’s favour. How does this relate to Oracle’s Linux move? Well, let me clear the threats that have been proposed already, which I mentioned were passing around the blogosphere/news article space.

First, if Oracle intends to eventually fork Red Hat’s distribution, so what? It’s been done more than once before. Mandriva is such an example. The GPL licensing mechanism has proven over and over that FOSS forks do not necessitate a negative outcome. Often they lead to a spread of improvements in the ecosystem as a whole and all the companies that continue to participate in that spread tend to benefit. I mean, Red Hat is still around, and strong. Forking in the open source world ought to have earned a default view as growth rather than as problematic division. The freedom of the licensing schemes makes a FOSS fork wholly different than one in which the prongs are proprietary.

Second, I don’t see why this should be viewed as Oracle just trying to hijack just Red Hat’s support business. Maybe I’m missing something but that’s only one aspect of what is at play. The fact is that Oracle offers products that run on Linux. Red Hat offers products that run on Linux. Some of these compete (application servers, database servers, etc.). Furthermore, competitor Microsoft offers enterprise solutions and the OS. These companies are getting their tentacles around more comprehensive offerings for their customers. At least that’s what the advertising is always promising. So what is going to be the easiest, most painfree choice for a customer? Getting pieces of a solution from a combination of vendors? Or getting something from start to finish that eliminates

• further evaluation time and effort
• additional sales points-of-contact
• extraneous support sources when trying to solve problems
• integration woes

It seems to me that all of these eliminations would result in a much more attractive choice for the customer. It would save a lot of time and cut down on the efforts required to get well-designed and supported enterprise systems. Consider how Oracle has positioned this move, reiterating its “unbreakable” theme and stating that

“Oracle validated configurations provide easier, faster, and lower-cost deployment of Linux solutions in the enterprise with pre-tested, validated architectures–including software, hardware, storage, and network components–along with documented best practices.”

If this support move is Oracle’s warning shot, then I think it’s a shot of the lean and comprehensive solution nature. Their phrase, which I quoted above, is spot-on with the model I outlined for a real year of the Linux desktop, it’s just focused on the enterprise software space instead.

Considering Oracle, Microsoft, and Red Hat, who can actually do this? The all-proprietary vendor, Microsoft? The mixed proprietary/open source vendor, Oracle? Or the all open source vendor, Red Hat? Based on those three options, only Red Hat is actually in the position to fulfill this comprehensive model because it’s the only one that operates entirely in the FOSS ecosystem and for that, again I refer to the comprehensive and lean model, which I outlined previously.

I’ll leave this post with a question. Where is Canonical in this? Every blog and article talking about Oracle/Red Hat seems to ask or fantasize about Canonical and Oracle teaming up. Thus far Canonical is publicly touting only support services. Will it catch up on the OS market game change to offer the sort of solution Red Hat currently has the potential to? That Oracle seems to want to do? That Microsoft tries to do but limits itself under pounds of proprietary rope?

A lucid read from AMR Research (I found this by way of The ERP Graveyard), which nicely discusses issues involved in enterprise software consolidation. I’m linking to this because I just mentioned in my previous post, the notion that the Infors (Golden Gate Capitals) of the world may be buying all the enterprise software vendors they can in order to accumulate maintenance customers and thus the revenue from those customers.

In some ways this may help the customers and AMR lists the reasons but there are also many problems this presents for customers. According to the AMR article, the strategy is likely concerned with packaging large customer bases (for future sale) rather than rounding out product functionality.

…this type of consolidation comes at a price that, unfortunately, customers must pay. By acquiring many competing products, aggregators tend to reduce competition within a market and cast the pall of acquisition over the remaining players. Because it is very expensive for customers to switch their enterprise applications, most companies have little choice but to stay put, pay maintenance, and hope for the best. While they may have had great leverage with the small vendor that originally sold them their software, they have little with their aggregator today.

So if the majority of a company’s IT budget is going to old projects I suppose this could be quite a concern. Unfortunately, and this may have been beyond the scope of the article, AMR did not really comment on how this affects innovation in the products.

I just read Alex Fletcher’s first piece of the Open Source Software Bedrock. He delineates three layers, namely, evaluation, adoption, and integration. Evaluation is what the other layers get stacked upon and altogether these make what he’s described as a supporting foundation for the policies, practices, and standards of the software’s life cycle. It seems to me that a guiding phenomenon inspiring the article is how FOSS changes the traditional selection/purchase process. Fletcher states:

“The traditional model of contacting a vendor, arranging a demo/sales pitch, wading through marketing fodder, etc. has been replaced with a model that shifts the balance of power from the vendor to the end user/customer.”

A point on this balance of power that I’m not sure surfaced in the article, is that sometimes a potential customer to an open source software firm has already downloaded, installed, and sampled the software before contacting the vendor for support or other services or products. (This is likely to be true, less frequently, when addressing totally proprietary software.) It means that the customer, on contacting a FOSS vendor, is doing so from a potentially more informed stance about what it requires from the vendor. This could also make it easier for the vendor to understand what is most valuable to provide the client. In other words, I’m not completely sure that this change in model necessarily shifts the balance of power. Perhaps instead, it shifts the needs assessment and provision processed in a way that might benefit both sides.

Fletcher makes a point that this “…paradigm requires a more prepared and motivated end user/customer…” which I appreciate though I also think, in some ways, it also aids that end. Another couple points that I thought were well-put and would like to address are Fletcher’s statements:

“It is a high priority to understand the exact support terms for a given piece of software, in line with any anticipated needs as revealed during the evaluation phase.” and “If the evaluation layer is done haphazardly the according adoption and integration layers will lack the proper support to be of any value.”

I believe this leads right into one of the greater points on evaluating an open source solution, which is how to ensure ongoing, stable, professional support. It seems to be a fear raised repeatedly by potential adopters of open source software. Yet that is the basis for many, if not the majority, of the vendors building their businesses around open source software. The support options are available so the customer must make sure it identifies the proper ones, which may not be that simple. I think, like other software evaluation practices, it is important to systematically identify business requirements from the different stakeholders within the company. Once those are well-understood the customer should thoroughly evaluate how potential vendors compare on all of the requirements.

A resource for evaluating open source IT and Linux service providers is the FOSS Evaluation Center. It offers about a thousand criteria addressing different support requirements a customer might have of a vendor, and it lets people compare vendors on each point. I designed those criteria, so it’s a bit of a plug, but it can be accessed for free, and I hope it’s useful. Another resource that might be useful toward the evaluation end (though I don’t have any experience with it) is a site called Find Open Source Support.

Martin Schneider at The 451 Group commented on whether the collective “we” can be too jaded regarding some proprietary vendors’ apparent embrace of open source methods. This was in response to a piece by Dave Rosenberg and Matt Asay about subverting open source for sake of certain marketing purposes. Rosenberg and Asay essentially say that Microsoft and SAP have a well-known history of speaking out against Free and open source software (FOSS) and concepts.

Certainly, Microsoft and SAP have put effort and money into spreading fear, uncertainty, and doubt (FUD), and both have publicly made, sometimes very strange statements about or against FOSS. Yet recently, both are putting some effort into releasing bits in an open source method or else funding some open source development. Rosenberg and Asay seem to think there is an ulterior motive,

“Any outreach attempts from vendors who have worked for years to destroy open source should be taken with a grain of salt and a sharp eye cast on motivating factors.”

Or could this mean, as Schneider suggests, that these companies are beginning to join the community’s stance that open source “…is simply a better way to create and distribute software.”? Rosenberg and Asay seem to take that into account by acknowledging the project leaders for the open source initiatives within these companies probably are working in earnest–I can’t help but lean toward a bigger picture that, as a whole, there is something else, more involved, taking place.

It makes perfect sense, if you’re a proprietary vendor, to delve deeply into your FOSS competitors, and for several reasons. I believe there are serious reasons to be wary of such proprietary vendors’ forays into FOSS and at the same time to embrace that. Here is why.

First, any vendor has to know what it’s competing against. This is just standard good business practice, there are even industries devoted to supporting this idea–competitive intelligence. What better way to understand the new models undoing your traditional strategy than to emulate them and find out how they work. The more you understand, the better can you build your products to compete and win. If the FOSS community innovates new technology, Microsoft wins by learning it and improving upon it for their own products, just like any good open source vendor would want to do (of course an open source vendor would participate by feeding the community with those improvements as well).

Second, what about that often referred to Machiavellian notion of keeping your friends close and enemies closer? If Microsoft can successfully attract an open source development community into its fold (so-to-speak) it gains a very powerful tool, a foothold into the “enemy’s” camp, which allows it to anticipate and prepare its proprietary strategies.

Third, does it hurt the proprietary vendor in any way? They’ve got all their proprietary business and propaganda in full swing, everyone already knows about that. On the other hand FOSS and Linux are gaining recognition. I’ll make an educated guess that FOSS and Linux are still not as well understood, in concept, by the majority of business decision-makers, much less the public in general. I think they still lack the massive public feeling of acceptance that most software vendors currently enjoy with their traditional proprietary business models. However, as that understanding and recognition grows in positive ways, it can only help companies like Microsoft and SAP to be able to show they’re just as much involved in the leading edge of technology practices. It’s simply good PR. If Microsoft and SAP can manage this while maintaining their proprietary side, so much the better for them (from their perspective).

Fourth, let’s suppose there truly is an ulterior motive to subvert FOSS communities. In the shoes of a company like Microsoft, it makes sense to blur the lines of differentiation between your proprietary approach and real FOSS approaches (hence the shared-source initiative). The harder it is for critics, detractors, or enemies to clearly differentiate your approach from their own, the harder it will be for them spotlight your weaknesses and their strengths, thus the customer cannot act on clear information for his or her software selection decisions. Furthermore, if you actually do participate in some ways with the FOSS community, you may gain some supporters that will defend, in good conscience, your motives, and possibly even turn a blind eye toward some of your other, less savoury practices (this not only blurs more boundaries but it again helps with grassroots PR, which is oh-so important on the Internet).

Finally, I’d like to say that already there is no clear side-versus-side here, we have to pay attention to the grey to really comprehend the situation. While I think we can see companies like Microsoft and SAP employing some intruiging strategies for subversion, and there are battles between models and methodologies, to a degree there is also some learning and the adoption of new and better practices. Because of the co-opetitive nature of FOSS models, the gradual adoption by the likes of proprietary vendors may even, unexpectedly, end up subverting those vendors’ models. We’re not too jaded to be constantly wary and suspect these companies of efforts to undermine FOSS, but we should, at the same time, cheer them on when they actually do participate in real FOSS processes.

Today, I had a conversation with a consulting firm that works with TEC‘s decision support tools and knowledge bases (KBs) on enterprise software. In this case, they were engaged in an ERP selection project.

The consulting firm was asking me about the data accuracy (in our KB) regarding the functionality of some of the vendors they’d shortlisted. TEC researches and provides immense amounts of information on software products so it is an incredibly tricky task for us to ensure that the data is accurate and timely. Considering the number of clients using our evaluation services for their projects, as well as the consultants using the same services for their clients, it amazes me when a software vendor either isn’t amenable to providing updated information about their products, or in a few cases, is less than truthful about their products’ capabilities. That’s what I want to talk about in this post because I had to answer this consultant honestly, without bias, and what I explained to him about the way one abnormally naughty vendor treated the RFI response process, seemed to slightly sour him toward its product.

First, usually vendors respond in earnest to our RFI inquiries, it’s in their best interest. I wonder though, if a few vendors respond dishonestly while knowing TEC exposes its analysis data to thousands of customers (who may very well become sales for the vendor), how well are these vendors responding to the inquiries they receive from individual clients that don’t have many resources for vetting information? I mean to say, if you’re working on a project to select some kind of enterprise software system, design your own custom RFI, and send it out to a bunch of vendors, how are you going to be sure that the responses are truly accurate? Even consultants won’t have expertise on every product out there.

It seems to me that until you get to a stage where you’ve already selected a few vendors to give scripted demonstrations, there isn’t much of a way to verify the accuracy of the responses; and how much time will have elapsed just to get to that point? I’m not suggesting that vendors are likely to act in bad faith, criteria are also commonly misunderstood. Even with a focussed team of subject matter experts, editors, and translators, we get inquiries from very knowledgeable and intelligent people that don’t understand criteria we use for our data collection.

Here’s a way that fails. I once worked for a company that had a slick on-line decision support/analysis tool called Compariscope. Our analyst team would actually get copies of the software from the vendors and set up test environments. This ensured accuracy in the data but it also meant the scope of the analyses was extremely limited and because of the significant time required, we were always playing catch-up to the latest software releases. Perhaps, it could have worked if we’d had hundreds of analysts, vast supplies of equipment, and the vendors were all willing to give us copies of their software (often they responded to requests for software as though we’d handed them a cleaver and asked them to cut off their left leg for lunch). That business model quickly evaporated. So installing and testing every type of enterprise software application is not a feasible methodology for an anlyst firm, much less the end user company.

When I started working with TEC, we only covered discrete and process ERP systems, and at that point, we only provided data for about ten vendors. Our ERP analyst, PJ, could check out the information and have a decent idea if the vendor understood the RFI and made an earnest response. But a single person cannot verify every one of over 3,000 criteria and as we grew and started providing information on more software vendors and on more subject areas (SCM, CRM, etc.) it became quite difficult to make sure all of the data were accurate. Even with additional analysts, nobody in the world really knows what every product is capable of.

I’m curious to know if, anyone that might read this (consultants, people that have worked on their own selection projects, etc) has come up with some good methodologies to verify data after gathering your own RFI processes before spending serious time in product demonstrations. Please respond with your thoughts. Here is what we came up with.

TEC demands RFI responses from an official of the vendor that is responsible for replying to client RFIs. Then we take a few steps to vet the vendor’s data…

1) Once we retrieve a completed RFI, we have a team of people give it a quick review, checking for obvious errors and such, if it passes that test, it moves on, if not, it goes back to the vendor for revision.

2) Our analysts start reviewing the information based on their own knowledge and experience of course, but also things like the RFI being internally consistent with itself (if you’re careful there are some ways to structure an RFI like this). Benchmarks, using TEC decision analysis tools. Analysts also have to constantly be aware of what’s going on in the field so that they can see consistency with known customer results, peer findings, news, conference announcements, and vendor sources such as collateral, other products, services, and initiatives.

3) I came up with a veridical comparison method that aggregates all our existing vendor responses to the criteria in a knowledge area (ERP for example) and defines what the likely level of support would be for each criterion. This lets analysts flag criteria where a particulare vendor deviates far from an expected range and understand what the next most likely levels of support are. For example:

If we know that only two in thirty ERP vendors (at any tier) natively support a standard interface to CAD systems for direct data access, and we see a start-up vendor telling us this criterion is fully supported, our analysts know they’ve got to see the vendor demonstrate that. The reverse is true as well. Sometimes a vendor says it doesn’t support criteria “out-of-the-box” but when we talk to the vendor, or it demonstrates how its system works, we realize the vendor simply misunderstood the criterion. That’s a great opportunity for us to learn how to clarify the criterion’s wording.

4) As I hinted above–the demonstration. All of these checks can go only so far. When an analyst actually sees the vendor demonstrate its capabilities, he or she can definitely verify the accuracy of an RFI.

Finally, even with the checking, benchmarking, and reviewing, sometimes, within the thousands of criteria, an error falls through the cracks. Sometimes, admittedly, even we are not quite fast enough. On occasion a consultant or VAR, intimately familiar with a product, alerts us to an error. Other times a customer is already using some product and tells us about an error in its ratings on our system.

Perhaps it would have been best if we’d discovered these errors first. But, in my opinion, this is one of the great strengths of having information like this being accessed by so many people with different perspectives via the Internet. As FOSS communities and other collaborative projects like Wikipedia has demonstrated–a little effort from many people can go a long way to improve a common goal. In our case, making sure we maintain accurate information on enterprise software products. I’ll admit this cross-checking process is probably not very transparent to the public. Perhaps a more transparent and collaborative cross-checking process would be a method to further improve data accuracy.

Niall at NetDimensions Insights wrote up two nice pieces pointing out a few ways that people seeking a learning management system can use low-cost tools to compare the different offerings out there. He mentioned both the Brandon Hall feature comparison document as well as the LMS RFI templates that Technology Evaluation Centers offers–this is what caught my attention. Niall comments that

Use of this template does not mean that you do not need to perform a thorough analysis of your organization’s learning management requirements. Each organization will have a unique set of requirements and you should ensure that any additional requirements identified are added to the template.

That’s exactly it too. Templates like those can be helpful to research functional requirements/support requirements, and ultimately toward soliciting proposals, but any spreadsheet-esque comparison grid will only do so much when it comes to analysis.

In any case, I wanted to respond by pointing out another inexpensive tool a potential LMS purchaser could use, which is TEC’s online LMS evaluation tool. It has the same hierarchy of criteria as the spreadsheet, except it lets you prioritize those criteria based on your organization’s learning requirements (and can include additional custom criteria). Then it analyzes your priorities to figure out which vendors match your requirements (of course it uses rated vendor responses to all those criteria to do this). I think this supports, at least in part, Niall’s recommendation for a thorough analysis.