Reply to proprietary cms know when to fold em
I’m a huge fan of open source and the benefits that a passionate and expert community of developers can bring. A slight annoyance of mine is when commercial companies use the open source debate for their own commercial gain, while dismissing the efforts of other commercial venders in the process. I’ve started to see a worrying trend towards this, encapsulated by a recent post by Aquia.
I wrote a reply to the author, copied below, I’d welcome thoughts and whether anyone else finds the trend both annoying and worrying…
–
Dear Scott,
I read your article with interest and felt compelled to write to share my experiences in this area. I also have 20 years’ experience with IT services, the last 14 on commercial browser based application development.
In summary, I think you have succeeded in attracting attention to Acquia’s passion for Drupal by trying to ride the open/closed source debate, congratulations on the traffic that has generated to your business. If I ever need a Drupal solution, I know where to come:)
Regarding your post:
—
“1) Vendors suck you dry. Partners make you succeed.”
Absolutely agree that a key ingredient in a typical CMS project is a stable long term services partnership with all the companies involved with the client.
Regardless of whether there is a software vendor in place, all must put the client interests at the centre.
In terms of vendors sucking clients dry, this is not my experience; perhaps you’ve been poorly treated at some stage? CMS vendors would not survive if they took this position, they exist to invest in areas where there is commercial gain, but if real client value is not delivered then their existence will be short lived.
Open and closed source vendors often charge for implementation and service fees. I don’t agree that charging for things automatically means that you exist purely to suck clients dry.
“2) Any technology can be utilized poorly. Proper assessment is key.”
I find the most useful evaluation is to determine the benefits you want from a solution and inspect the features of products that realise those benefits.
Most vendors allow for a download trial version, if they don’t then perhaps avoid.
I’m really not sure that many clients would want or benefit from inspecting the source code as part of their evaluation.
Also talk to existing clients, join user groups and speak to people using the software.
“3) One dimensional depth only makes you flat. Scale spherically to outpace the rest.”
I agree with the benefits that a great community brings, but you seem to limit this community to Drupal partners, many closed source vendors facilitate and actively support community development.
Having a global community of active contributors is very common in both open and closed source solutions.
“4) Roadmaps stunt your growth. Innovate at the pace you require.”
All major CMS vendors I’ve worked with have a core infrastructure that can be extended to suit client requirements. Having to wait for a vendor is a very old model which I’m sure is limited to very specialist, niche markets nowadays.
There is nothing wrong with a central vender providing a vision/roadmap. In fact these are usually driven by community feedback and market trends, something most clients would find some benefit from.
There is no distinction here between open source and closed source vendors if an open, extensible framework exists (which I believe it does with most major vendors).
“5) Reactive support is no longer sufficient. Today’s needs are more comprehensive.”
It makes perfect sense to me that a vendor supports the core and a partner supports the customised solution, this model works across all forms of IT and consumer products.
Partners should have the confidence to trust the core products that they promote, this also allows the partner to focus on the real business benefits realised by deploying the overall solution. Discussing whether the partner should see each line of code feels pointless.
–
Whether to hold’em or fold’em?…If your trusted partner understands your business and efficiently provides robust services that help you meet your business goals, I’d hold’em, regardless of preference to open or closed source.
Regards,
Phil Broadbery, Client Services Director, cScape.
Posted by admin | CMS
For me companies that implement OpenSource solutions are vendors.
They just don’t sell product but knowledge how to customise and implement existing opensource solution for customer needs.
Your last sentence sums it all up Phil
Great response. I would add that “Also talk to existing clients, join user groups and speak to people using the software” ties in with Scott’s statement for point 1 – “Interest in your success is secondary. Their primary goal is to win all of your chips”. In my opinion, successful projects leads to happy customers, who are willing to provide positive references, which help develop new business.
I’m going to stick up for Acquia on this one.
It’s not correct to think of Open Source as just a pricing thing. And it’s incorrect to think of it as a development methodology thing too, because not all Open Source is a community development (our CMS, ocPortal, isn’t developed in anything like the same way as Drupal is).
The big point about Open Source that people don’t seem to quite get is that you have the source, so after deploying you are not locked in.
It’s all about avoiding LOCK IN.
All the pre-planning in the world that consultants love to do is not going to protect you from the unexpected, but if you are locked in there’s a big big risk you’ll have to start almost from scratch should the vendor not be able to flex to your demands.
All kinds of things could happen to a vendor to screw you over. What if they go bust? What if a competitor buys them and tries to migrate customers to a less suitable product line? What if they’re too busy to deal with you quickly? Or too expensive? Or hike the prices? Or they start only working on projects over a certain price threshold? Or not skilled enough? All these things can change, so talking to existing customers or testing them, can’t protect you.
If you have the source you can literally get some people from Pakistan to do your programming, should you wish to. You can employ someone. You can learn programming and make minor tweaks yourself. Whatever you like. Agility is important, and so is flexibility. Don’t believe you can do that with APIs, and don’t believe that vendor support services are always going to be able to meet the demands you have. What if you want a recent phD to implement the results of his thesis into your existing project? He/She’d probably need the source code, and you don’t want to have to get the vendor to employ them, or negotiate some source code sharing deal.
Old-school consultant and RFP behaviour irks me a fair bit. There’s so much process and measurement on some pretty etherial stuff divorced from the actual value generation, and the actual true quality of products, and it handicaps big time, and it hurts progressive companies like my own who want to generate value without all this fluff. As the UK government have recently found, minimising your exposure to contracts and controls, and working primarily via employing/contracting skilled developers to work using good open tools, on an ongoing basis, delivers far more value. When people are untied from vendor contracts, licenses, project contracts, and so on, and can develop in the open and iteratively, everyone is comfortable just to move ahead with agility. And if developers do a bad job you can fire them and get different ones – but what you have to that point is not diminished, and you’re not bound by dodgy commitments.
Hire good people, and let those good people stand on the shoulders of giants. Start thinking about the quality of the technology, your ability to leverage it without dependency on the original developers, and the skills of the implementors you choose. Don’t tie yourself up.
Google, Apple, Facebook, etc, they are all now built on Open Source toolsets. It’s time for wider industry to realise that you need to consult with people that do things the same way – the days of trying to manage binding x-hundred-k contracts upfront are over – there is no need to, and it’s a corrosive business for all concerned.