Is The DAM Software Market Sleepwalking Into Becoming A Digital Sharecropping Business?

This is the first of a two-part article series, the second item is now published also.

In the last 4-5 years, some trends have been subtly and gradually developing in the DAM software market.  Their cumulative effects are more significant than is being widely acknowledged.  Based on my conversations with a number of end users, vendors and investors, I know there are a number of others who have had similar thoughts.  In this article, I want to try and draw together those perspectives.

The trends I am referring to can be summarised as follows:

  • The now ubiquitous use of Cloud delivery for DAM solutions.
  • The blurring of the lines demarking different varieties of content digital asset solutions
  • The decline of innovation and the homogenised nature of most DAM software
  • The dependence of DAM solutions on a small range of embedded suppliers.
  • The rise of ‘near DAM’ as opposed to (and at the expense of) ‘DAM Lite’.

I will examine each of these in this article.  In a follow-up piece, I will consider the characteristics of some solutions or strategies that could be applied by the DAM market to avoid the more negative consequences they might bring.

Ubiquitous Cloud Delivery

Cloud delivery of DAM solutions is now the norm rather than the exception – even in the enterprise segment.  I am not going to argue against using the cloud as it is, by far, the easiest method for both end users and vendors for many different reasons and makes everything far simpler than was once the case.  It has, however, led to some unexpected outcomes which are beginning to pose more of a challenge than many might have anticipated.

In February this year, I wrote an article about political issues with using an Enterprise Service Bus to coordinate interoperability between solutions (especially Enterprise Digital Asset Supply Chain requirements).  As described in that piece, more Digital Asset Supply Chain solutions now rely on multiple DAM technologies: whether introduced by a single vendor acting as a primary contractor, or end users deciding to bring in multiple providers as part of a strategy they have devised themselves.

In the past, when everything was deployed to an organisation’s own internal network, it was sometimes easier to force reluctant vendors to collaborate with each other and even if they refused, the use of shared databases and other core infrastructure (which the IT department controlled access to) made it virtually impossible to actually stop anyone from taking matters into their own hands.  Integrating software using direct connections to databases and file servers rather than through APIs is nearly always a bad idea, but it nearly always used to happen anyway either due to laziness, intransigence (or both) on the part of one or more solution providers.

With cloud delivery, that option is not usually on-offer because the required data is walled-up in the vendor’s own heavily-defended castle in the sky and they are now the sole arbiters over who gets access to it.  If one counterparty refuses to play nicely with everyone else, sanctions are required to get them to behave (a fact which increases the friction associated with DAM interoperability where it should be the opposite).  Clearly, not all vendors behave in this fashion and many lack the necessary clout to resist these demands even if they wanted to.  As should be apparent, however, if anyone decides to be difficult, they certainly can be.  It is ironic that in many of these integration disputes, a lot of cloud vendors start to sound like the in-house IT departments they once railed against when promoting their product to prospective end users.

The underlying theme here is control and the shift in the balance of power.  Those who employ cloud services to deliver their solutions have to make a choice between either settling for a state where they are the junior partner subservient to someone else who has more influence than they do, or they seek to dominate every available profitable market niche and dilute their offer as a result.

Blurring Of The Lines Of Differentiation Between Product Categories

This point is closely related to the preceding one.  DAMs, are no longer simply ‘media warehouses’ as they might have been once (which is a positive development).  They must integrate with WCM, MRM, PIM and a range of other adjacent toolsets.  Further, the more aggressive vendors of these associated products now also claim they provide some of the capabilities of DAM solutions or even offer the whole piece themselves.  The same is true in the other direction too and a number of DAM vendors flirt with changing the name of their product classification to one or other fashionable descriptions that the pay-to-play analysts are eager to promote.

There are two factors driving this: wanting to secure a far bigger slice of the budget pie and/or fear that an ambitious competitor will come along and eat their lunch.  These are not at all mutually exclusive and in many ways, they are simply the greed and fear sides of the same psychological coin.

When I talk to clients who are considering upgrading DAM solutions, often they will mention how they have a spoken to a vendor who operates in an adjacent field and asserts that their product ‘has DAM as well’.  The complexity of the Digital Asset Management problem is routinely underestimated, but that never stops ambitious salespeople from claiming their product has solved it (even though subsequent deeper analysis usually reveals that rarely to be the case).  The reverse is true also and DAM vendors who tell their prospective clients they ‘can do MRM/WCM/PIM (delete as appropriate) as well’ have also frequently underestimated the scale of that challenge.

In nearly all DAM requirements I have been involved with, the client would be better off getting dedicated, best-of-breed systems that are highly focussed on solving one specific problem, rather than the ‘fornicate with half the farmyard’ technique that vendors are sometimes prone to experimenting with.  While suites give the appearance of being a neat and tidy solution to a lot of procurement complications, the actual benefits often turn out to be illusory as the business ends up with a solution that doesn’t do anything particularly well.

The fact so many vendors inside DAM and adjacent to it have attempted to develop a DAM solution means that there is now a basic level of core technical knowledge about the subject.  Even moderately talented developers can now assimilate enough knowledge to give the impression that they have the skills required to deliver a credible DAM solution.  These contribute to the sense that DAM is now ‘nothing special’ and further weaken the business case for investing in a fully-featured one.

The Decline Of DAM Innovation

The demise of DAM innovation is a topic that has been extensively covered on DAM News before so I will not labour it again here.  I believe, however, it is more of a symptom or composite of the other factors described in this article and that partly explains why it remains unresolved.  As such, readers can consider this item the answer as to why no one innovates in DAM very much any longer.

Dependence On Key Embedded Suppliers

A contributory reason for the lack of innovation in DAM is the far greater dependence on some key large suppliers and/or toolsets.  Some of these are open source projects like ImageMagick or FFMPEG etc rather than businesses, per sé, but the effects are similar, nonetheless.

To illustrate this, let me ask a question: who is the biggest company in DAM?  It could be argued that it is Amazon.  Although many might counter that they do not sell a DAM software product, probably around 75% of DAM vendors use them for storage, transcoding, content delivery, application services and an array of other core components.  A lot of DAM firms would find it difficult to keep trading if these dependent services they are heavy users of ceased to be available for only one or two weeks.  To an extent, this risk can be mitigated by using multiple suppliers from other providers like Microsoft, Google etc, but what should be clear is that DAM vendors are the tenants rather than the landlords in this business relationship.

Nothing stops Amazon, Google nor Microsoft from offering DAM solutions and if they wanted to, they could wipe out large swathes of the competition overnight very easily.  Apart from the PR impact that kind of manoeuvre might have on the perception of them by their other cloud hosting customers, the hard-headed business reason they do not do this is because the DAM software market is unappealing for them due to its small size and the cost/complexity of managing customers.  It is far easier to provide services and let someone else deal with the problems of the end users – the ‘sell the shovels’ argument which is often used in these contexts.

Viewed from one perspective, the DAM industry has turned itself into a channel partner or integrator business model which depends on a small range of key suppliers to continue to exist.  This goes a long way to explaining why there are so many DAM vendors offering homogenous systems that are delivered and marketed using nearly identical methods.  If you view the current DAM systems market as largely an aggregate of similar operators who have slightly different implementations of the same set of services, they start to look a lot more like conventional channel partner or VAR (Value Added Reseller) businesses that can be found in sectors like IT hardware.  In these markets, participants usually compete on price or ability to successfully implement product (i.e. consulting skills). To use an analogy: if all the chefs use identical ingredients, there is a higher probability that their food will all taste the same, whatever restaurant you decide to dine in.

This kind of reductionist analysis is useful from an economic perspective to assess the who holds the influence or power in the DAM market, but as discussed earlier, this also radically underestimates the complexity of the Digital Asset Management problem domain when it comes to delivering solutions that generate ROI for end users.  To re-use my earlier analogy, although the chefs might use the same ingredients, their level of skill and expertise can substantially affect whether they can produce a dish you actually want to eat.  There is a risk, however, that these kind of subtleties are going to get ignored by many DAM users, either to save money or (more likely) because they don’t know any better.  I can foresee a potential scenario where the DAM software market blurs itself out of existence and I would argue that this loss of definition is already taking place.

The Rise Of ‘Near DAM’

Last month, Ramon Forster wrote an article for CMSWire about Dropbox and its silent takeover of DAM, especially for a core DAM use-case: sharing files.  There are some elements of this piece that I can partly agree with:

File sharing tools are the de-facto standard for not just file sharing, but also creation and collaboration. Given this, file sharing tools literally own what the DAM industry was invented for, offering us DAM vendors more competition than we wished.” [Read More]

I would question whether the original reason DAM was invented was file sharing.  It is more the ability to associate metadata with a digital essence to give it context so you can find it to do something useful.  Digital files on computer systems are a conceptual metaphor  (i.e. a form of metadata) invented to link together non-contiguous blocks of data stored on a storage medium like a disk or tape etc.  They are still digital assets.

I have to accept, however, that these are mostly semantic arguments and practically speaking, sharing files is what a lot of DAM users have in mind when they think of what they do with their DAM on a daily basis.  In that respect (and for the same reasons I discussed earlier with reference to vendors who claim they offer DAM) Dropbox draws more users away from DAM.

Later in the piece, there are some interesting conclusions reached:

… independent DAM software vendors should not try to compete with file sharing tools in creative collaboration and operations. Refraining  from doing so will relieve us from spending thousands of men-hours for features such as file synchronization, creative review & approval management, brand resource portal building which all needs to be super-easy to use by marketeers and their clientele (notably always on on all devices).  Instead, let’s integrate all these bespoke features that we get ‘for free’ from the file sharing tool vendors. Have us then revisit our own DAM software core strength which I believe is being the one-stop inventory for master content, managed using powerful metadata capabilities.” [Read More]

I say ‘interesting’ because I don’t agree with Ramon, however, I might have done once and I can see the logic from a complexity and cost-saving perspective.

The arguments in favour of using Dropbox have some similarity with those for using Cloud infrastructure.  What is the point of re-inventing a whole array of basic services which are likely to be incompatible with anything else available when you can just use those already built by someone else who is much larger, better capitalised and who already has market traction?  The majority of ancillary tool vendors who develop tools to extend DAM solutions nearly always include an edition which is compatible with Dropbox.  They are now becoming an interoperability ‘standard’ solely by virtue of their size and reach.  As such, this argument has some commercial logic to it – at least until you examine the longer-term implications.

The ‘for free’ phrase in Ramon’s article should offer some portents of trouble ahead, especially viewed in the context of the recent news about Facebook and their mining and exploitation of user data via applications that were also offered ‘for free’.  Not too long ago, I was approached by some people who had the idea of building a DAM based on Dropbox using their API in the manner that Ramon describes.  We did an analysis which considered the investment opportunities and risks of using this kind of strategy.  As might be expected, the cost argument was a highly compelling one, however, the big risk was that this could turn into not much more than a digital sharecropping business model.  Those who pursue this strategy cede control over their customers and the core technology to Dropbox, who take the role of the Lord of the Manor.  If Dropbox deem that DAM presents a more interesting business proposition than they once thought, they can pillage their tenant farmer’s lands and do away with them relatively easily and far more easily than Cloud infrastructure services providers like Amazon etc who would have to do some work before they could offer a direct alternative themselves.

There is an ignominious history of larger tech vendors competing with their own channel partners when they discover that they might have something of interest to them and it seems possible that this could happen here.  If the extent of the vendor’s ambitions is to operate an entity which provides them with an alternative to paid employment (and where they are willing to risk losing everything they have worked to establish in a potentially very short period of time) this might be acceptable, but this is not a platform on which anyone can build a sustainable and scalable business.  This is moving from having a product where you own the IP and which has some prospects for growth into becoming something like a consultant for-hire (and you can take it from the author of this article that you won’t get rich with that strategy).  The software market is such that not many customers are likely to be willing to pay by the hour for someone to provide them with working product.  They will want their cake (the fully functional DAM solution) and to eat it (properly supported and all for a fixed and highly competitive cost).

From a purely technical perspective, the other issue to contend with is what happens if Dropbox decide to change their API protocol?  This has happened in the past and although they give notice periods, they are not required to do so.   I suspect many vendors will eventually take up the Dropbox option anyway.  Many might be those I referred to earlier who operate in some other market who see this as an expedient and low-cost method to start competing in the DAM market.  If there is one clear trajectory which points towards the demise of large numbers of dedicated vendors, however, it will be when they relegate themselves to becoming Dropbox implementation consultants.

Currently, a lot of DAM vendors are in a far more financially secure state than they would have been a decade ago.  To an extent, established DAM software businesses can still enjoy years of profitability with little or no investment in the platform and only retaining a minimal support resource – this is the sleepwalking phase which is alluded to in the title of this item.  Without anything to differentiate themselves, however, that is likely to be eroded incrementally to nothing over a period of time.  Many firms might not care and could be willing to see out the next five years seeing a gradual managed decline in their revenues.  I don’t think that is universally the case, however and there are many companies that are far more ambitious than that.  With that in mind, they should carefully consider whether moving the farm to the land owned by Mr Dropbox is a wise decision for the long-term sustainability and growth prospects of their business (which in quite a few cases is also likely to also be their biggest financial asset).


Control, centralisation and the relentless eradication of unique selling points in the DAM market are the overriding themes of this piece.  For the reasons described in the preceding section, I do not believe that handing over ownership of a DAM vendor’s digital infrastructure to Dropbox, Amazon or any other cloud services operator offers anything like long-term stability – the opposite, in fact.  Neither, however, would I argue that entirely eschewing these services and hosting bespoke products with private data centres or on internal network is a very good strategy either.

To survive and prosper, the DAM market needs a better settlement than is currently being offered.  While this might superficially appear to be only the concern of the vendors, the implications touch everyone who has a stake in Digital Asset Management, including end users and investors who are strategizing about whether to take positions in DAM technology.

If DAM software platforms either disappear or become an amorphous blob of homogeneous functionality which clings to the centre of the bell-curve, they will end up offering limited value for a large section of end users and demand will fade away as a result.  Some calculated risk-taking and new capital to back it up is now urgently required, especially as those who currently have the means now appear to just be washing money between their positions rather than actually investing in DAM innovation.

It is exceptionally easy to criticise DAM vendors (and many of them do themselves absolutely no favours in this respect).  Simply making a critique of their poor decisions, however, is facile and nihilistic.  Offering cynicism alone (while acknowledging that it can generate some entertaining copy for DAM trade publications) is of limited practical value.  With that in mind, in the second part of this article, I consider some solutions which I believe could avoid the potential outcomes I have discussed in this piece.  In the meantime, I welcome any comments on my conclusions, whether you share my view, or hold an alternative one.

Share this Article:


  • There are so many perspectives on this, it is amazing. You think of the *current* state as “Sharecropper” while I think of the *old* (circa 2013) state as “Sharecropper.”

    We seem to be on opposite sides of this equation.

    I built many DAMs in the 1990s, but we didn’t call them DAMs back then. Any print production facility had to manage their assets, so we dealt with it.

    How hard, truly, is it to build a “DAM”?

    To this day, the best home-built DAMs I’ve seen hold their own against most “product” DAMs.

    Because it’s not truly that hard, to interrogate metadata, to store assets, to manage versions and revisions, to let users access assets according to roles. And scalability is an ever-moving target, so it wouldn’t be something that any current DAM has attained.

    And DAM is invariably just ONE PART of the workflow, whether it’s content creation, content management, rights management, publishing, archival, you name it.

    From my perspective, we were “sharecroppers” when companies like MediaBeacon, NorthPlains, “Autonomy” and OpenText dominated DAM back in 2011-2013.

    I think we’re much less sharecropper-like with the Bynder, Widen, Nuxeo, Adobe, Style Labs, MediaValet, Photoshelter, DALIM, etc. advances of the past 5 years. Storage systems like Dropbox and Box can be elevated by layers such as Crooze.

    The only constant is change, and you need to embrace it. DAM is better than ever today, and will be awesome within a few years. The key is interoperability, modularity, standards support, and focus.

  • Thanks for your comment, Max, I’m not sure I can agree with you on much of this, however.

    You say the following:

    “You think of the *current* state as “Sharecropper” while I think of the *old* (circa 2013) state as ‘Sharecropper.'”

    You’ve misunderstood me. I think it is in danger of becoming like sharecropping, not that it is already. I’m defining ‘sharecropping’ (in a DAM software context) as using someone else’s technology as your application’s base and having to keep paying them to continue to use it, even when they could wipe you out if they wanted to. Further, I’ve made particular reference to Ramon Forster’s recommendation to use Dropbox as a basis for DAM – which I believe is effectively sharecropping. The same would be true for Box and (to a lesser extent, Amazon, Microsoft and Google). If your solution has dependencies on them for core application services like file storage etc, you are subservient to them whether you like it or not. That’s an undeniable fact. I challenge you or anyone else to explain how anyone who builds on these services does not have a junior position in the business relationship, just as if you rent property, you are lower down the scale than the landlord who ultimately owns it. This is basic capitalism at-work (and not even the free-market kind, hence the analogy).

    On your point about ‘old’ DAM, I disagree that Mediabeacon, Northplains, Autonomy or OpenText ever dominated DAM. No one has ever cornered the DAM market to-date. I also don’t agree with those timelines, in 2013 there were still hundreds of DAM companies, no one had even 2% of the DAM market back then and they still don’t now. Most of the firms in your second list (which I will deal with later) existed in 2013 and a number of them had for between 5-10 years beforehand and that they had been active in DAM also.

    DAM software products have has not changed much since 2013 (arguably several years before then). Nearly all DAM users from 2013 could start using equivalent platforms in 2018 with virtually no re-training and in most-cases, only requiring about a 30 minute ‘re-orientation’ period. While the architecture and techniques used to implement product might have been updated, this was largely a self-inflicted problem of the vendor’s own making where they rapidly added lots of functionality without thinking very much about how to do it (the ‘features arms race’ as we called it on DAM News). For most end users, DAM systems are still remarkably similar to the ones from 2013 and probably more like 2010. Vendors and people like you who sell to them might think there have been big changes because of the amount of work invested into improving scalability and staying up with current technological trends in delivering or implementing applications, but as far as everyone else in the world is concerned, they are essentially not very different. If you disagree, read this article by Martin Wilson of Asset Bank who is one of your current partners: In particular this:

    “The products available now are fundamentally very similar to those on offer 15 years ago. Back then I remember describing a digital asset management application as “a searchable database of digital files”. That’s still a pretty accurate one liner.”

    My article is about the state of the DAM software market. While your firm (as developers of ancillary tools for DAM) might have viewed Mediabeacon et al as the Lords of the Manor, they aren’t as far as most DAM software firms are concerned, they’re just a few competitors who’ve maybe been around a while longer than some others. I don’t understand your comparison of those firms, specifically, with sharecropping? To my knowledge, no current DAM vendor who has an autonomous solution they developed themselves (i.e. not a reseller or partner etc) ever paid money to Mediabeacon, OpenText, Northplains or Autonomy simply to offer their wares to customers. I don’t know if Silicon Publishing had to, but it’s irrelevant anyway because your firm are not DAM vendors. They are your customers, not your peers.

    On this point:

    “I think we’re much less sharecropper-like with the Bynder, Widen, Nuxeo, Adobe, Style Labs, MediaValet, Photoshelter, DALIM, etc. advances of the past 5 years.”

    Why? Do you mean ‘we’ as in ‘Silicon Publishing’ or the wider DAM software market (which is the subject of the article)? I note most of the firms in your list are also present here too:

    Why is it different for the firms who also happen to be customers of Silicon Publishing? Why are they not likely to find themselves coerced into a form of sharecropping by using Box, Dropbox, Amazon, Microsoft or Google as a basis for their platforms than anyone else? I’m not sure your comments have relevance to the subject of the piece and it seems a lot like a back-handed PR comment promoting your partners and (by proxy) your own firm. If you disagree, I’ll need to see some relevant evidence to support your assertions.

  • Ah, sorry, I misunderstood. No, I am not promoting my “partners” – I was being honest about who I think is moving the stuff forward, and for every company I mentioned there are 2 “partners” that weren’t mentioned. I don’t think my mentioning a DAM matters anyway, I know about the ones we work with because these are the ones I log into so yeah these are “partners”, but I have a specific example for each one I named of how they’ve innovated in the past few years.

    I meant the wider DAM software market. I think DAMs are doing more creative things today than ever. I disagree with you and Martin Wilson.

    But, agreed, I didn’t read your article near closely enough. I mainly heard this sense of negativity about the current state, while I think it’s a fantastic and ever-improving current state.

    As far as “sharecropping” in the sense of using someone else’s storage infrastructure, there’s certainly some level of risk there. It would be especially bad if everyone used only AWS and there were a single provider, but thank God there are at least a few platforms (Google and Microsoft are here to stay, even if both remain somewhat behind). And there are still some cloud DAMs (such as Photoshelter) with their own respectable data centers.

    Still, I think it’s fantastic that there is this option for DAMs. It is an incredible advance. What it does is commoditize storage and CDN. Yes, it comes at a cost, but… no it is not at all a requirement that DAMs use this, they have the option of building on a platform such as AWS, Google or Azure that are low-level, or even higher-level applications such as Box or Dropbox (which I wouldn’t expect from the most serious DAMs).

    There is also the option of offering DAMs the old-school way, as pure Software, AND offering a cloud version, as we see with DALIM and Nuxeo.

    If DAMs want to build their own storage infrastructure/CDN/virtualization technology, they certainly still can. How, exactly, are they being coerced?

    I mainly see more options, more possibilities, and a growing market attracting new ideas and new energy.

    I guess I see with Box or Dropbox how you could sense “coersion” – because they do a fair amount of pretending to be DAMs, while they are primarily storage platforms. Unlike AWS, Azure, and the Google cloud, these provide a pseudo-DAM “ready-to-go”. So the foundation of Box or Dropbox are suspicious, as they go too far at providing the fundamentals: not so with AWS, Azure, Google.

    If I saw every DAM decide that they just had to base their stuff on top of Box or Dropbox, I’d be concerned. But AWS and Azure are so low-level, so incredibly flexible, that I have only recently seen any level of “DAM on top of Box or Dropbox”. The DAMs that I consider most serious either offer their own hosting in their own data center (rare but it happens), host in AWS (most common from the ones I know) or host in Azure. I imagine someone must be hosting in the Google cloud or some other cloud but I haven’t heard of any.

    I am sure there are hefty payments made to Amazon and Microsoft, and yes we are to some extent at the mercy of the biggest beasts with the economy of scale to support global cloud deployment, but there is not a monopoly, and the biggest/best players are offering low-level stuff. The DAMs then can focus on the higher-level features. Tell me how AWS, Google Cloud, Azure provide any pre-conceived concepts around:
    * Workflow
    * Metadata/search
    * Rendition generation/management

    Box and Dropbox may be doing this, but I think both do so poorly compared to a real DAM and Cloud DAMs are using AWS and Azure (some also offering raw software that can go anywhere) so they can build what they think the best layer on top of that infrastructure.

    I hate paying my Amazon bill but I love using AWS because it lets us focus on the software instead of the infrastructure grunt work. If they had a monopoly I would be very worried but I know for a fact that they don’t. Box and Dropbox both have their own wonderful qualities and serve specific markets: if someone like Crooze can turn Box into a useful DAM, more power to them. This would help some organizations stuck with Box for the rest of the business. It certainly wouldn’t monopolize the DAM space.

    Isn’t DAM growing in usage over time? You don’t think anything new is happening? Maybe I didn’t know about the great things of 15 years ago, but what I see in the current DAMs is that they tend to have sensible updates where things actually improve, there is a healthy competition, and I would much rather be buying a DAM in 2018 than in 2003.

  • Max, as my teachers always used to say (and no doubt everyone else’s) if you don’t read the question, you can’t hope to pass the exam.

    “I mainly heard this sense of negativity about the current state, while I think it’s a fantastic and ever-improving current state.”

    But you don’t have a very positive opinion about DAM interoperability, do you? At least you didn’t about a year ago:

    So, lots of products that aren’t very different from each other, yet still manage to be incompatible and now the CEO of a DAM vendor writing in major trade journal suggests Dropbox should be used as the basis for most DAM solutions because they ‘own the DAM market’ – see the CMSWire article I reference: What could possibly be wrong here?

    “As far as “sharecropping” in the sense of using someone else’s storage infrastructure, there’s certainly some level of risk there”

    That’s the thesis of the piece, the clue’s in the title: “Is The DAM Software Market Sleepwalking Into Becoming A Digital Sharecropping Business?” There is indeed ‘some risk’ there, quite a lot actually for all the reasons discussed in my article (once you’ve had a chance to read it).

    “they have the option of building on a platform such as AWS, Google or Azure that are low-level, or even higher-level applications such as Box or Dropbox (which I wouldn’t expect from the most serious DAMs)”

    Yes, but there is indeed a proposal that ‘serious DAMs’ use Dropbox, hence why I quoted from Ramon Forster’s article where he argues exactly that. Some people in DAM really are suggesting that now and far more in private than in public. There’s a big difference between public vendor PR and what they tell you in private about their growth prospects and fears for the future sustainability of their firms.

    “Isn’t DAM growing in usage over time? You don’t think anything new is happening?”

    No, I don’t think DAM is growing at anything like the rate it should be. Few VC or private equity investors in DAM technology believe those ‘DAM market worth $7bn+’ reports that get churned out by all the ‘research mills’ in Pune who charge $4k for a report on DAM they’ve cribbed from vendor press releases (I know, because I talk to private equity firms who tell me they think they’re nonsense as well). There is a lot of digital media being produced, but DAMs aren’t doing a great job of helping people manage it. This is like saying because people are buying your umbrellas that it means they are an amazing product, rather than because it’s actually just raining a lot and they need something to stop themselves getting wet. The demand is not because the vendors make fantastic tools, it’s because everyone is swimming in digital media/content assets.

    “Maybe I didn’t know about the great things of 15 years ago, but what I see in the current DAMs is that they tend to have sensible updates where things actually improve, there is a healthy competition, and I would much rather be buying a DAM in 2018 than in 2003.”

    I never said there were ‘great things’ 15 years ago, neither did Martin Wilson in his piece, which I take it you’ve not read properly either? You’re attempting to change the narrative because you don’t have an argument that stacks up. The basic modus operandi of DAM solutions is the same as it was in 2002. Martin is exactly right; there have been updates, but no one is really ‘disrupting’ DAM – they just say they are because they think it sounds hip and cool. There’s the same basic grid of thumbnails and a search field, with a lightbox feature. I’ve been looking at about five major DAMs in the last week for a client and they’re all ever more alike than they used to be. The demand for anything to help (however imperfect) from end users is currently masking some serious underlying structural defects in the wider market that will ultimately get solved, but not in a way that many on the sell-side of DAM will like.

    I disagree about the competition also. There was plenty of it in 2003 as well (as there is now). Far more than just Mediabeacon, Northplains and OpenText as you’ve tried to suggest. For example, there was Canto, who have been in DAM since 1990 and WebDAM (formerly known as ‘Spitfire Photo’) who date from around 2004, Adobe’s DAM was acquired from a company called ‘Scene 7’ who were founded in 2001, Brandworkz who were formed in 1997, Asset Bank have made DAM systems since 2002. This is just a selection of firms taken from your own list of partners (and I’m sure I’ve missed a few of those who were also around in 2002). There are hundreds of others not on your list and many of them are still around to this day. I reckon I could name somewhere between 50-70 on my own and get up to three figures quite easily with some assistance from others.

    DAM has never been lacking a steady of stream of people willing to try their hand at implementing it. You said that you had seen in-house DAMs which were better than ‘product’ DAMs. So if the amateurs can still beat the pros at their own game, where is the evidence of rapid improvement by the latter? How come a large newspaper publisher still decides to build their own product rather than pay for one: To make it clear, I don’t recommend the ‘build it yourself’ strategy, but the fact it is still considered as a serious option indicates that the DAM software market hasn’t done a great job of solving the end-users problems, to-date. Ask yourself how many people still think about developing their own spreadsheet software these days?

    If you want to set yourself up as an apologist for the DAM software market and make reassuring noises that ‘everything will be fine’ and ‘we’re all doing great’ etc, go ahead. I guess the vendors are your customers. Mine, however, are the end users and they are rather less prepared to be as accommodating of the current situation as you are.

  • I have to agree with you Ralph. DAM now and DAM “back then” (it seems like time has stood still) doesn’t seem all that different, which in turn makes trying to procure a new system that much harder. How am I to help decide for my employer which system will be the best fit when they all are the best fit and at the same time are not? It is ubiquitous indeed to me not just in the realm of delivering via the cloud, but on every point this vendor or that vendor tries to make to appear different and “cutting edge”. I can’t choose a solution because “the UI is really intuitive!”

    I’ll definitely be on the look out for your follow-up.

  • Nick, you have my sympathies with selection exercises. What you say is a familiar refrain I hear from loads of different people.

    I’d have to tell you my follow-up is unlikely to offer a great deal of assistance to DAM users right now, however, I am hoping it will lead to some of the vendors to pause for thought. A lot of the senior management of DAM software firms are smarter than the impression they sometimes present (at least at demonstrated by their sales and marketing material) but trust (or the lack of it) is also a big problem – whether that is of themselves or anyone else, for that matter.

Leave a Reply

Your email address will not be published. Required fields are marked *