Open Source v traditional Software (ding, ding, ding)

At the tail end of last month I spent two days attending talks at the yearly Internet World exhibition. I always enjoy listening to speakers and the quality was, by and large, very good. On the final day CMS Watch (@cmswatch) hosted a panel discussion in the Content Management theatre entitled: “Open Source v Traditional Software”. It’s was a strange title, I thought, as the line, for many vendors, between open and closed source becomes more and more vague. This blending was, however, represented in the panel, which included Stephen Morgan (@stephen_morgan) of Squiz – a commercial open source vendor.

On the whole the panel was very good and the debate interesting. The open source contingent argued eloquently  the pros of spreading knowledge throughout the community and of the response times to bug fixes compared with the release cycles of proprietary software. One of Stephen’s responses when asked for reasons to go with an open source system, however, struck me as – at best – ill conceived.

Stephen had argued that as a customer of a closed source software retailer you fall, entirely, to their mercy in terms of functional changes. The assertion was that when you – as a customer – have access to source code you can modify it to suit your needs. Conversely, he claimed that changes to a closed source solution could only be requested, may never happen and would be subject to a lengthy release cycle even if they were implemented.

Now I’m sorry but that is just not the case; as I told the panel once the discussion was opened to the audience. The software I work with, Nstein’s WCM, features an expansive and  well designed extension framework to do just what Stephen was referring to. In fact, I went further and put the polemic to the panel that hacking core source code is obviously not desirable and severely hinders an applications upgrade path. Stephen’s countered with the fact that changes made to the code-base can be submitted to Squiz (or almost any other open source software maintainer, for that matter) and may be committed into the core application.

Before I start a holy war here (and a succession of flames in this sites comments) I would like to state my position on open source: I love it. I love the concept. I love free software. I love the freedom to modify and distribute software. Basically, I get it. I’m a huge fan of Linux and at the end of the day a PHP programmer. Just yesterday, I spent my Saturday contributing PHPTs (that’s PHP tests, for non-geeks) with the PHP London user group. I really do dig open source. Also, for the record, I thought Stephen Morgan represented his brand and community very well and I enjoyed his commentary; this is not meant to be a personal attack 😉 .

In fact, this post is not criticizing open source software at all. The discussion here, as far as I am concerned is about best practices. Okay, sure, one can modify the source code to an open source project and that change may be incorporated into the software. May be incorporated; probably won’t be. And with closed source software that option is not available – you have less choice. But that is, I think, a good thing.

At least the prelude to a good thing. Software evolves, like all technology, and the beautiful simplicity of Darwinian evolution applies. It’s survival of the fittest. If we, at Nstein, were to compete with open source CMS projects with a solution which was not customisable, which had no mechanism for modification we would have died out. The fact is we make a vast amount of customisation possible – we’ve had to. Because we don’t encourage customers to delve into the core source code (it’s a PHP app so they can if they really want) we’ve had to employ other methods. Extensible object models built around best practices derived from industry experience. Plug-in frameworks. Generic extension frameworks. If one of our customers cannot extend or change something that they need to the chances out that another client will at some point want that same, absent flexibility. So, through good design practices we have constructed a system which clients can (and do) modify, yet when they decide to upgrade to the next point release it is a trivial process.

Now, I’m not saying that open source software is poorly designed. I’m writing this piece now on WordPress – a fantastic example of an open source project – which features an extremely rich and well documented plug-in framework. The sheer number of plug-ins and themes available for WorldPress is a testament to the system. And, as with Nstein’s software, when I upgrade WordPress all of my extensions still work (at least 95%, or more, of the time).

I doubt anyone would disagree with the merits of a plug-in based system. My interest, however, is in this question: how much of a temptation is there to hack open source software? I know I’ve done it in the past. I’ve heard a number of times that Drupal upgrades are nigh on impossible due to the nature of the inevitible customisations a Web content management system requires. I’m not in a position to answer that question authorititively, and I won’t attempt to. I would like to stir the debate up though. So, thoughts, please….

2 Responses to “Open Source v traditional Software (ding, ding, ding)”

  1. * full disclosure* – I am Chris Scott’s manager at Nstein…

    This is certainly an interesting discussion topic… one that comes up regularly in my work as Product Strategist with Nstein. I certainly think some open source projects can be extremely effective and better than commercial applications. And I, like Chris, believe strongly in open source. But to choose an open source solution because “we can always rewrite it if we don’t like it” isn’t really viable for companies who do not see application development as their core business. Publishers struggle with this all the time. Sometimes having a world-class vendor providing support and responsible for the product vision is preferable. One area where I see this is in making the hard choices that separate a great product from a toolkit or a tinkerer’s paradise that drives the end users crazy.

    I often contend that as something gets more complex, its ultimate success depends not only on the obvious features and benefits but also on well-designed constraints. There is no reason why open source projects can’t be managed with constraints (Apache, Firefox, WordPress, etc.), but sometimes the end users just want to get work done with a minimum of fuss. I quite like Linux – and Ubuntu is pretty cool – but I’m now so busy that I pay Apple to provide me with a OS and software that just works without a lot of effort on my part.

    At the end of the day, there’s no real “right answer” for everyone. Open source can become a dead end just as easily as commercial software (and maybe in some cases open source is at greater risk). Jump on SourceForge and look around – there’s a lot of dead open source projects (I’ve been waiting for almost two years for an LCD Smartie update and if I could find anything decent would pay for something less crash-prone!).

  2. Hey Chris – great post!

    Sorry it’s taken me a while but I’ve finally written back!!!

    The basic idea behind my response is that open APIs and extension frameworks for proprietary products are fantastic. But they only address one part of what makes Open Source Software valuable.

    As Chris Hill says, different customers want different things. And OSS is by no means the answer for everyone. But the people who do choose it treasure it for a wide variety of reasons – extensibility is only one of them…

    See the full post here

Leave a Reply

Your e-mail address will not be published. Required fields are marked *