You are here: Home » Vendors » The Guardian Release Open Source ‘Grid’ DAM System

The Guardian Release Open Source ‘Grid’ DAM System

by Ralph Windsor on August 18, 2015

UK newspaper, the Guardian recently announced that they had released their new in-house image management system as an open source application.  There is an article about this by one of their developers, Sébastien Cevey:

For about a year, a small dedicated team has been building the Guardian’s new image management service.  From the beginning, the vision was to provide a universal and fast experience accessing media that is well organised and using it in an affordable way to produce high-quality content.  To deliver it, the team relied on a pragmatic Agile approach, working directly with users to quickly develop a product that fits their needs and expectations. The new service is now integrated with our print workflow and used for almost half of the images published in our digital content.” [Read More]

The article is interesting case study to analyse for a number of reasons, most notably the build vs buy decision and some of the management issues that result from the former option.  There is the open source aspect of this also, but I don’t intend to go over that extensively in this article as it is a separate subject in its own right which would be better addressed as such.  I am aware that for the majority of DAM News readers, the questions will be more management-related and along the lines of “should we do this ourselves?” and that is the perspective I intend to use for my discussion.

The name of the Guardian’s system, ‘Grid’ could be construed by some as an ironic comment on building your own DAM as opposed to buying someone else’s since one of the few common characteristics across the interfaces of practically all commercial solutions offered for around 20 years or so is the grids of thumbnail search results which they all usually have (especially on the image side).  I suspect that is reading too much into it, however and the reasons behind the name are rather more prosaic.

There is a bullet point list of the major requirements, which I have reproduced below:

  • Ingest and index all our images past, present and future
  • Very fast and powerful search
  • User upload, metadata editing, cropping, publishing of optimised assets
  • Rights management, historical usage records
  • Collaboration workflows
  • In-browser experience from anywhere
  • Integration with all internal tools
  • Deployable to the AWS cloud

Most of these do look like features that (on paper, at least) are present in quite a few DAM solutions, including those offered by a number of vendors who work with magazine and newspaper publishers as well as others who can count larger media businesses among their clients.  In addition, the video demonstration of their application does look very similar to many systems I have seen (in fact, they have made a pretty good facsimile of a typical commercial DAM, based on the UI presentation).  Sébastien offers this justification:

Build vs buy is often a difficult decision, and while there were systems that we could have bought in, they were typically expensive, a poor fit with our existing technology, or not yet shipping. On top of that, they would all have required various levels of customisations to fit our needs, at the risk of complicating future software upgrades…When we spoke to our colleagues in other publishers, we found they had all encountered the same challenges.” [Read More]

If you are contemplating a similar decision about whether to build or buy a DAM, you must be prepared to undertake detailed research before choosing the ‘build’ option since the overall balance of risk does tilt in favour of buying something that a vendor has already invested time and money into the development of, although as I will discuss, it isn’t completely one-sided and there are a number of factors to be carefully considered.

To help with the process of eliminating pre-built options, there are quite a few resources available (many of which are free, or at least relatively cheap compared with the cost of a typical DAM implementation exercise). We currently list 81 vendors in our directory and although we don’t charge any money for vendors to sign-up, we do review each entry and exclude anyone who is not really offering a DAM solution.  I gather Capterra are less fussy than we are and will accept anyone who claims their solution is a DAM application.   They also actively market their directory far more extensively than we do, so they have a higher volume (189 vendors when I checked earlier today).  DAM Foundation have also validated 30 systems for their 10 Core Characteristics standard.  If you are prepared to pay money for an evaluation, Real Story Group are generally acknowledged as offering the most credible and comprehensive research regarding the DAM software market out of all the options currently available from analysts who cover this sector; they currently feature 41 vendors.  Lastly, I gather that a hybrid build/buy option that a number of organisations choose is to use an open source system and modify the code as necessary.  Although it is in need of updating, the list of open source DAM systems compiled by my predecessor offers a reasonable starting point for anyone favouring that option.

As alluded to earlier, there are two points which do mitigate in favour of their decision to build their own application: collaboration workflows and integration with internal tools.  The method used to implement workflows can have a profound effect on which solution (if any) is a good fit and the significance of this aspect has been discussed by others before.  When selecting DAM systems or deciding to implement your own, all the key users need to be reasonably comfortable with whatever workflow strategies are either offered by the vendor’s product or built by an internal development team.  A few months ago, I reviewed Roger Howard’s article about workflow and this presents some arguments which have some similarities to those advanced by Sébastien (i.e that most of the options they looked at were essentially not up to the job).  A lot of care is required, however, to ensure that the assessment of the complexity of the task is not skewed towards the internal option just because everyone is more familiar with it, so involving an in-house third party in the decision making process (who will not be hands-on) can offer a more balanced perspective.

The other point which is perhaps more compelling is the integration with internal tools.  While a vendor’s product will usually start quite a bit further ahead of the internal choice for any generic features that are common requirements of their other customers, integration projects (are out of necessity) nearly always custom-built professional services assignments.  Some of them might be easier than others due to the techniques and methods used by both parties, but the odds are probably in favour of an internally-developed solution integrating more easily with existing in-house tools because everyone is more likely to know each other and has greater awareness of the potential pitfalls (and how to avoid them).

As you can see, there are some finely balanced judgement calls that need to be made and a great deal depends on what resources you have at your disposal.  I will note that the Guardian obviously have an extensive on-line presence (and I would imagine that aspect competes with, or exceeds, the print edition in terms of revenue).  The same is not necessarily going to be true for other organisations and therefore the availability of skilled resources to implement custom internal applications which can go toe-to-toe with commercially available alternatives might not be a feasible option.

Based on Sébastien’s comments about their discussions with staff from other publishers who encountered similar issues to them, it could be inferred that publishers (in general) are not being well served by the DAM options currently available, however, I do know a little about that market (more as it applies to books than newspapers or magazines, however) and another reason might be that publishers tend to have complex and demanding workflows which don’t usually follow the same models from one firm to another and are all unique, which makes the implementation task more complex than it is for other industries.  Further, budgets at publishers seem to be far thinner than many other sectors (at least, they always seem to say they are!)

For most, an off-the-peg DAM solution is still likely to be the safer option, not least because if something goes awry with it, you can call upon the vendor to put it right, but the choice is not 100% clear-cut.  If nothing else, the article is useful to encourage DAM users to consider the full extent of the options available, in particular if they have more demanding digital asset management needs than those clients who the candidate vendors normally service.

Related posts:


Leave a Comment

Previous post:

Next post: