Blog

Yesterday I was at an event, Harnessing Free and Open Source Software in Local Government, organised by Public Sector Forums. I was actually presenting a case study on Kent Connects Portals, a project we have been working with that is a Plone Portal for various groups of people within the various Kent Connects partners (councils, fire service, etc).

It was great to show how the project had evolved, and how they were able to pick up Plone out of the box a few years ago, and setup a useful service with very little cost; then how as their project and membership grew how they were able to partner with Netsight, get an SLA, support, further development etc. To me this is one of the key benefits of Open Source, the way in which you can start small an incrementally build up. You can choose how much support you need, when, and who will provide it.

The whole event was actually pretty good [*], with quite a few speakers talking about various aspects of Open Source. However I think one of the highlights for me was actually the keynote right at the start by Simon Phipps, the Chief Open Source Officer from Sun Microsystems. What struck me mainly was how similar what he was talking about echoed my own experiences of promoting Open Source, and I suppose more specifically selling the whole concept of Open Source to businesses and organisations.

One thing he said that suddenly made the bulb above my head light was to do with procurement. At Netsight, we pretty much gave up on responding to blind tenders we were sent many years ago due to the overhead of responding to them. Not just that but we always thought that the tenders generally asked 'the wrong questions' which made it very hard for us, as an Open Source implementation company, to really give a decent answer. Many of you, no doubt, will be familiar with this scenario as an example: The tender has a cost table you have to fill in the blanks in. You are not allowed to deviate from the format of the table (because the tenderer wants to try and compare apples with apples). So you fill the table in, but your numbers just don't quite fit in the boxes right. We've even had feedback from tenders we've lost saying things like 'Well your solution costs 0 for licensing and 50K for implementation; the solution we chose cost 40K in licensing and 30K in implementation, so must be the more appropriate solution for our needs'.

Now I can see their thinking here. Our solution cost 50K and 100% of the cost is in implementation/customisation so obviously wasn't the correct solution to start with. The one they chose cost 70K but only 42% of that was implementation/customisation. What they don't realise that (especially in the CMS market) any large software procurement is only going to give you a fraction of your requirements out of the box. That is because every business is different, and so no one piece of software can do everything you need. Open Source might give you slightly less out of the box than a commercial offering, but that is generally because Open Source software focusses on delivering a lowest common denominator out of the box, whereas commercial software has loads of bells and whistles (many of which you will never need), but more on that later. You are still going to need professional services to tailor the software to your specific business and its requirements. The problem is looking at ratio of costs and the perception of these ratios.

The bit that Simon said that made the bulb go on in my head? He said that most companies set out on a procurement process to procure a software license. That is what software is to them: licenses. That is what they know, and that is how they think. If you've ever had the fun of dealing with the contracts/procurement department of a large company you will recognise this thinking. And so with that goal in mind, of course they end up succeeding in their quest to procure a license for software.

That is why the procurement process is so alien to us... we don't sell software licenses. Put another way, we don't sell what it is that they are trying to buy. Note that I said what they are trying to buy, not what they actually need.

To make matters even worse, these procurement processes end up so long and expensive for both the tenderer and the software vendor, that the vendor has to recoup the cost by adding it on to the software license. Lather, rinse, and repeat this process a number of times and you will soon see why it is often said that 70% of the revenue of commercial CMS companies goes to their sales and marketing depts. And... its not really the vendors to blame! It is the tenderers that do these long winded procurement processes in the first place that started this.

You then end up with a situation that if you are going to end up buying a 100K piece of software, you expect it to be pretty damn well worth it. And how does a commercial software vendor justify that high price? By having a feature list as long as your arm; or by implementing absurdly complex and costly protocols (example from Simon: CORBA, etc). Again, how many of us have looked at the end result of a tender process and said 'Well I could implement that in a handful of lines of python and a nice REST-ful API for a tenth of that cost'?

The final bit of advice: look at the exit costs of a piece of software as part of your costings when looking at systems. Something vendors are very reticent to tell you is how much it will cost to move away from their system at the end of it.

[*] Apart from them managing to somehow not print name badges for us, despite being speakers. And them censoring the delegate packs by actually removing the What is Open Source? / What is Plone? brochure from the info packs we'd sent up with the case study info.