When Open Source meets procurement

One of the challenges that I've seen growing over the last few years is that of Open Source technology and the traditional company procurement cycle. I'm not talking here about Open Source companies such as Redhat featuring JBoss but about those Open Source projects like Hibernate, DROOLS, Tomcat or even things like Log4J, small scale projects like GroovyRules, and even those smaller open source companies out there. These are all technologies that would meet a large number of business requirements, but they don't get used as often as they should and more "feature rich" commercial products are used as the industrial steam powered hammers to crack every nut.

So why is this? The main reason is, IMO, the procurement department which has failed in most companies to react to the changing software market. Companies tend to have "approved" lists of suppliers for software and these lists are arrived at in one of two ways

1. Projects had a need for a specific type of software that needed them to buy something
2. The company wanted to rationalise its suppliers for a certain type of software

When a project wants to use Open Source it will tend to just use it, the key here is that this information is not fed back into procurement so the product can go onto the approved software list. This is done for two reasons

1. Its too much effort
2. If procurement knows they might try and block it as it isn't already on the list

If however there might be a product purchase, money, involved then procurement will go through a standard process to select the approved software, this will involve putting out a Request for Information (RFI) to a long list of suppliers with a standard set of questions. These responses will then be collated and graded with the long list being reduced down to a short list of a few vendors who will then be set a Request for Proposal (RFP), vendors will then respond again and a winner will be selected and contract negotiations will begin. Key factors will be :

1. How well the product meets the requirements
2. Financial stability of the company
3. How cheap is it and what discount did they get on list
4. Fit with current suppliers (less suppliers are easier to manage)

The problem with this approach is that it is fundamentally aimed at traditional software vendors who can invest the time, and money, into the response process and who have a recognised brand backing them up with the accounts to match. This approach just doesn't work when Open Source technology should be considered. The first problem is who do you send the RFI to?, most of these Open Source projects are federated, almost all don't have a sales team, so there is just nowhere for the procurement department to send the RFI to, which means Open Source has already "qualified out" of the process.

Lets assume that they do find out who to send the RFI to, the next problem is getting someone to respond to it, Open Source developers aren't going to get paid any money if the company selects their product so why on earth would they spend time responding to the RFI? Again this means the Open Source project is unlikely to respond to the RFI and will again be qualified out. Maybe they do respond and the procurement department goes through the checklist, it doesn't look good for Open Source as you couldn't produce any accounts for the last 3 years proving you are a stable company. Failed again!

So you think that is bad don't you? Procurement should make more effort. But how can they make that effort? You see here is the problem, the objective of the procurement cycle is to do it as cheaply as possible (what is the point in spending $10k to determine the right product for a max spend of $100k) this means pushing work out onto the supplier as much as possible. To evaluate Open Source means the company would have to respond itself to the RFI/RFP which brings in lots of compliance and competition issues and also means that the company would have to approve budget towards funding the response process for that Open Source product, in otherwords instead of pushing cost downwards Open Source actually means an increase in cost for the company during the evaluation process. Sure you can argue it might save money in the long run, but today that is $10k the company doesn't have to spend if it doesn't want to.

How do I get to $10k? Well lets assume that the "internal" billable rate is $500, this is the number the accountants say that a person costs the company. You can't just say "we'll do the RFI response" you have to think that you are going to do the full response (after all if you don't get to do the RFP then as internal people you should be shot as you know what is needed) so lets say 2 people 3 days for the RFI response, RFP to include a bit of a demo so 2 people for 10 days for the RFP, 26 days in all, which at $500 would be $13,000, hence calling it $10k because you'd have to keep it to that mark to get it signed off.

Now lets assume a miracle occurs, and an Open Source product gets through to the RFP process and even get all the effort to required respond. The procurement department is now faced with a question of how it gets support for the product, how it contracts for the product, what the upgrade cycle should be, how it matches feature for feature against the competition etc etc. The trouble is that this turns into a "My bucket is bigger than your bucket" competition. The products that win aren't always the ones that meet the requirements the best, they are often the ones that offer the most "value add" aka "bells and whistles". Here again Open Source comes a cropper as the product are normally, GUIs in Linux and emacs aside, built for purpose rather than for a sales campaign where these extras can be spun as being "free" or "included" in the price. Very few of these assessments actually involve building demos, beyond showing what the vendor already has, to prove that the technology works for your requirements and are often just a run off of analyst assessments and powerpoints of features.

The financial assessment is a key one, most Open Source projects don't have a company and if they do the company is pretty small and won't have the clout of a big player (imagine someone in procurement comparing Spring with .NET and looking at Interface21 v Microsoft in the assessment). If you are doing this internally you have to convince people that you will be able to do the support, claiming that the resources on the internet, the community of developers will help doesn't wash with procurement, why would anyone do anything for free? They will ask, this is the finance department remember. You need to be clear about the cost of support, examples of where you've used Log4J for instance.

The procurement process was hasn't changed in well over 10 years, back then Open Source technologies were few and far between and rarely competed with their commercial equivalents, today however we need a new procurement process and this needs to be one that aims not to buy the "ultimate" solution but to deliver products that do what the business wants. This means thinking how products work in the small, medium and large projects or at different levels of complexity. It also means a different set of criteria for evaluation.

What procurement needs to do is start looking at fit for purpose and actively having that proven, to include Open Source in this means that the company will actually have to invest its people's time into that process. Procurement will also need to actively look at free alternatives to the commercial products and work out how to assess the solution. This leads to a simple conclusion.

For Open Source to be included in a procurement process the IT organisation must be responsible for the assessment and recommendations. If an Open Source product is selected then there is no reason for procurement to ever be involved. The IT organisation should assess based on fit for purpose and on its ability to develop and work with that technology. If support is going to be needed then again the options need to be assessed with Commercial software becoming stronger in this area. Procurement should put down the basic criteria, but it should not be governing or leading the process. If it comes down to contractual negotiations then procurement should become actively involved in securing the best deal.

The key question here is how you secure that $10k to fund your assessment of the Open Source equivalents, and how you keep that assessment honest (most vendors would qualify out if they feel they just an external stalking horse). The only real way to do this is to have people on all of the product assessments working actively with the vendors, this way you can compare your internal team with a properly supported person from a commercial vendor, this gives both sides something and makes it a fairer fight. Trouble is this costs even more money and time from people who could be on more business valuable work elsewhere.

Building the business case for this sort of approach isn't simple, linking it to a project and having each team (no more than 3) build the same project functionality can help but still gives redundancy of effort. It really requires an IT department to understand the value of getting the right tool in, and making sure that the tool works. The first thing you are going to need is data for your case, do you have examples in your company where a commercial product (spent money) was replaced by an Open Source equivalent? Do you have examples where the procurement process selected and purchased a product which didn't perform on the project and causes issues? Do you have examples where picking a specific product made it difficult to get people with the right skills which meant getting in expensive contractors?

Gather this information and work out the cost over the last 12-24 months to your company of the current procurement approach. This then gives you the basis to argue for a more interactive procurement cycle and one that includes more hands on work. They key is that you are not proposing to allow Open Source in, but to be more rigorous on all vendors to make sure the company doesn't make the same mistakes again. The Open Source angle just becomes a happy side effect.

Open Source doesn't currently get used as much as it should, and a major reason for that is that its not available to businesses via their normal procurement process. So either procurement has to change or Open Source needs to think about how it responds. Changing procurement means you need to think in their language, money, and be able to demonstrate that the current process has cost the company money, thus justifying the investment to fix it. Changing Open Source would be like boiling the ocean.

Technorati Tags: Open Source