Thursday 11th March 2010 by James Skinner

Give us the widgets

“We’ve got to have a Twitter widget” – one of the key phrases used by web teams in 2008 and 2009. Prior to that, the best thing since sliced bread was having a Google map on your Contact Us page, or perhaps a nice AJAX-powered dynamic postcode lookup gadget. The truth is, some popular new technical tools are here to stay and others will fall by the wayside. The challenge for any organisation looking to take advantage of these emerging tools is the sheer pace at which they appear, gain ubiquity and, in some cases, drop off the radar.

The likes of Twitter, Facebook, LinkedIn, YouTube, Flickr and hosted applications such as Google’s Docs and Spreadsheets, combined with the latest generation of mobile devices, has meant that the traditional approach to software development simply doesn’t cut it anymore. In short: it’s just too slow to respond.

Roadmap inertia

If you’ve looked at vendors of content management systems, CRM platforms, finance systems and virtually any other type of software, you’ll know all about “the roadmap”. It’s that often-fictitious list of new features that the vendor is planning to develop, and you’ll get the benefit of sharing the development costs with all their other clients. The truth is that the existence of this list of new features means two things:

• 

  It’s hugely difficult to add things anywhere other than at the end of the list. Commitments have been made to other clients, planning and development work is underway and changing things is not a trivial task.

• In many cases, by the time new features actually appear, their time has passed and the advantage has been lost.

How do we know this? Because until 2007, we developed our own community and CMS platform; we had our own roadmap. Our clients often asked us for new features we simply couldn’t provide in a sensible timescale.

How can Open Source help?

The first challenge here is understanding clearly what is meant by “Open Source”, and part of that challenge is casting aside the tired definition: “a couple of teenagers in their bedroom writing shoddy code”. Open Source software simply isn’t a second-rate cousin of “proper” software development as it has been historically perceived. The likes of Drupal, Joomla and Plone have done wonders for the Open Source movement, establishing themselves as leading content management platforms, and adoption has spread into many other sectors – SugarCRM, for example. And that's before you consider the real housegold names of Open Source, like Firefox, Ubuntu and OpenOffice.

There are actually two key aspects that define the term “Open Source”:

• Open Source as a licensing model – it’s “free software without any vendor lock-in”
• Open Source as a development methodology – it’s “large scale collaborative coding”

Free Software

In all honesty, the cost of ownership argument is the least important aspect of Open Source software for me - there’s no such thing as “free” software. There might not be a licence fee and maintenance charge with Open Source platforms, but there’s still a cost of ownership in implementation, support, training and maintenance. Nonetheless, the lack of that six-figure upfront fee is a compelling reason to adopt an open approach. Vendor lock-in is another matter, though. We work with organisations every day who are effectively trapped with their supplier because no-one else can work on the code, even assuming the vendor will release it.

Collaborative Coding

This is where the real benefit of Open Source software comes into play. Imagine a small software development company with, say, ten developers and a couple of testers. They’re working hard on building some Social Media tools, some blogging, simple peer-to-peer networking, perhaps a recommendations and ratings system. Then over the horizon comes Twitter, gathering huge momentum and high-profile users, and rapidly becoming the microblogging service of choice.
What options does the software company have when their clients see Twitter feeds appearing on their competitor’s websites and want a widget to allow them to syndicate their feed on their own site?

• Shelve another feature in favour of the newcomer?
• Rush through a widget in the shortest time possible with minimal testing?
• Add the feature to their roadmap and hope that Twitter hasn’t vanished by the time they get round to it?

None of these are palatable choices.

Meanwhile, the 20,000+ members of the Drupal community are using the power of their sheer scale and ability to collaboratively build, test and roll out new features. So are the members of the community behind Joomla, Plone and any number of other Open Source platforms. It’s hard to see how traditional vendors could possibly compete.

What about the quality?

There’s an argument that rapid, collaborative development generates poor quality code and this often worries organisations who are about to invest heavily in technology. The truth is that the scale of Open Source development communities means that the sheer volume of people scrutinising and improving code identifies and resolves bugs hugely rapidly. More and more large organisations are adopting Open Source platforms lending more credibility to their security, performance and scalability. The White House, the New York Observer and the Mayor of London have adopted the popular Drupal platform, for example.

In his essay The Cathedral and the Bazaar, Eric S. Raymond proposes that  the more widely available the source code is for public testing, scrutiny, and experimentation, the more rapidly all forms of bugs will be discovered. Conversely an inordinate amount of time and energy must be spent hunting for bugs when code is available only to a few developers, such as in a traditional development model.

What does this all mean?

In summary, Social Media technology moves fast, and you need to arm yourself with a strategy that lets you keep up. In my next blog, I’ll explain why abandoning a 2-year development project and adopting an Open Source platform turned out to be the best possible way to achieve that strategy.