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.