Last week I attended an event organised by the BCS entitled Public Funds in the UK: Open Source for Document and Content Management?. I'll be doing a full write up of the talks, and indeed put up my own slides from the talk I did in the next day or so... but firstly I wanted to respond to a few blog posts that have come out of the event.
Three specific posts by: Jon Marks, Janus Boye, and Justin Cormack came out in the days after the events, prompted by the panel discussion at the end of the event in which there was discussion about and Open Source vs. Open Standards. Towards the end, the discussion got quite philosophical and the question of "What does 'Open Source' really mean?" was raised. I had to dash to catch the train, so missed the beers afterwards, but no doubt the discussion followed on in the pub.
The end result was Janus posting that he was confused as to what the real benefits are to Open Source, followed by two responses -- one by Jon explaining what standards are used in the CMS world, and the other by Justin talking more about the ethos of Open Source and pointing out that it was developers that first 'got' Open Source, followed by the rest of the world. As someone who is a developer first and a businessman second I guess I took some of those aspects for granted and it was good to read Janus' post to remind me that maybe not everyone sees things quite the same way as I (or other developers) do.
So where did this confusion come about? And what about this whole "What is Open Source?" question? Well let me try and recap some of the points that went back and forth in the panel discussion:
- The end user doesn't care if the product is Open Source or Proprietary... they just want the job done
- Does access to the source code really matter? If the system has an API, who cares?
- The license fee is only a small part of the cost of a project, so does it matter if I have to pay a license fee?
- Some proprietary vendors offer free trial versions of their software, so I can evaluate them just as cheaply as Open Source solutions
- Open Source means I can own the software
- I can do transparent, iterative, agile development just as easily on proprietary platform as an open source one
Now, these are all good points and thinking them through I can see they all have quite a bit of merit. In fact back at the office I was thinking through them all and it is a useful exercise to try and work out really what Open Source means to you as the more you think about it the more non-obvious it becomes.
The first point: does the client really care if they can access the source code or not? Brian Prentice from Gartner wrote a blog post last month comparing Open Source to the just-in-time manufacturing revolution of the car industry and how an end car buyer doesn't care (or even know) that the manufacturer uses JIT or Lean Manufacturing. The end buyer just wants a cheaper/better car customised to their specific requirements. How the manufacturer does it is not a differentiating factor to the buyer. So, on that basis, why should the client care whether a system is Open Source or not? Maybe the client shouldn't... but that doesn't mean that Open Source is any less valuable a proposition. I'm not going to tell Toyota that just because I don't care if they use Lean or not that it doesn't make a different to the end result.
So maybe it is true that 'Open Source' should not be the main marketing message for an Open Source CMS, and should not be the main reason on its own why that solution is chosen, but that doesn't make the fact that it is Open Source any less valuable.
At the moment though, Open Source is a very good badge to try and explain to the client why the product is different and can then be a way to explain the benefits.
Actually the car manufacturing analogy above falls down a bit, as when you buy a car most people don't worry about future extensibility of what they've just bought. Yes, they might want to know if you can fit a roof rack, or how much an annual service costs... but in that case, that is pretty much it. If we instead look at a commercial vehicle, say something like a council looking to purchase a municipal bus. The council will want to know that they will be able to get spares for the next decade or so for their vehicle. They are going to want to be sure that they can service the vehicle themselves if need be (maybe they have their own vehicle service dept.), they want to know that they can get ahold of a Haynes manual (or whatever the commercial equivalent is) for the vehicle so that they can do the service themselves. They will want to know that they can retro-fit a wheelchair lift into it if need be in the future. If they take it into service one day at the main dealer and the dealer tells them the flux capacitor is broken then they can take it to Joe's Garage down the road and get a second opinion. Oh wait, of course the main dealer wouldn't tell them something as preposterous as that! They know that would be daft, as they know Joe's Garage next door would tell them they are talk out of their a*%e. See what I'm getting at here?
If the system has an API do I really need access to the source code? Going the opposite way, one commenter to Janus' blog states he prefers not having access to the source as it helps delineate which bits of the system he can and can't change and that helps when it comes time to upgrade. I can see his point, and anyone who has naively gone in and hacked the core of an Open Source system without following the practices of that project will find themselves in a sticky situation when they come to upgrade. But as he states, unless an API exists to do what you want, you are stuck. If you need to bend a system in such a way that the API doesn't allow then you are out of luck. Then again, having an API doesn't mean upgrades will be plain sailing. Looking at the process for upgrade from Sharepoint 2007 to 2010 looks like it is going to be a far from simple.
The license fee is only a small part of a project cost, so it doesn't matter if I have to pay it. Open Source is not that much cheaper overall. Well this may be the case, but as I've stated before the figures just don't really add up on this. Either a company makes its money from licenses, or makes it from professional services. If all the proprietary CMS vendors say that the license fee isn't a big part and could drop it then I think they would be out of business pretty quickly. Unless they switched to doing more professional services of course... but then see the heat that Ektron have just come under this week regards to them allegedly cannibalizing their channel partners' prospective customers. You know that feeling you get when (in the UK) you take your car in for its MOT test and the garage swears there is no relation between their MOT dept and their service dept? Yeah? same feeling I get with proprietary CMS vendors.
On to Software ownership. There seemed to be a bit of confusion here, as some people seemed to believe that Open Source means you get to own the software. Quite the opposite. The whole point of Open Source is that you don't own the code directly but that it is owned by a collective -- usually by a trust or foundation (such as the Plone Foundation or Apache Software Foundation).
A very good piece of advice given to me many years ago by Paul Everitt (CEO of Digital Creations when they Open Sourced the granddaddy of web publishing platforms, Zope): 'Software is not an asset, it is a liability'. One of the big points of Open Source (particularly 'Community' Open Source as opposed to 'Commercial' Open Source) is that it helps to lower risk of software ownership by spreading the risk. This is easily illustrated by seeing what happens when a proprietary software vendor is bought out by another vendor. History has shown us that often companies end up with duplicate products in their portfolio and one gets dropped. Often these acquisitions are purely business decisions at a high level and can have little bearing on the actual product.
Again, going back to the CMSWire article above on Ektron there was a great anonymous comment that put forward the following scenario:
Interactive Agency (IA) evaluates a CMS product and it seems like a good solution. Perhaps they didn't test enough, or perhaps they assumed that because they were not yet "Certified" they simply did not understand how to do certain things. The marketing material looks slick, and the CMS has tons of ads all over the internet, so IA selects the CMS.
The CMS vendor participates in selling the product into IA's clients, talking up all of the great features and functionality. The clients are impressed and sign on the dotted line.
During the implementation of their 1st site, IA encounters what appear to be bugs in the CMS product, but chalks it up to inexperience. 2nd project, same thing. 3rd project, CMS vendor says "Yeah, we'll fix that in the next version." 4th project, it becomes hard to actually get support from the CMS vendor, but they say they are improving their support soon. 5th project, more bugs, more promises of what's to come. Eventually the new version comes out with the same bugs as the old.
If we look at IA's situation, they now have 5 clients tied into a CMS product that is clearly not all that was promised... a product that makes it difficult for IA to deliver what they promised their client when it should be making it easier. Their options are:
1- Publicly (in a forum such as this, or Twitter, or anywhere on the internet) talk about the negative experience they've had.
2- Keep quiet about the issues so as to not damage their own reputation (poor judgment in selecting a CMS solution), and look at a superior solution (having already gotten little satisfaction from the CMS vendor)
3- Post anonymously when they have a chance.
This doesn't even consider those developers who are not involved in the CMS selection process and are simply frustrated with having to work with a product they consider substandard.
That is a classic example of where a client (on in this case an integrator/agency) ends up beholden to a vendor -- this is where Open Source makes a difference. Open Source adjusts the balance of power between the client/agency and the vendor. In the case above, the agency could have either gone in and fixed the bug themselves (then contributing it back to the project so that they don't have to maintain it in subsequent releases) or paid someone more knowledgeable to fix the issue for them. Either way they are not stuck in a dead end having selected a CMS project and then being let down by the relationship with the vendor.
The relationship with the vendor is one of the most important aspects of a CMS deployment project, and as Jon said at the BCS event, very few projects fail due to the technology. They mostly fail due to project management issues, or relationship issues between the parties involved. That being the case why would you enter into a relationship in which one party holds all the keys? That just doesn't make good business sense.
OK, this blog post has gotten long enough, I better publish it now before or I never will! We can follow up in the comments.
