I often read Edward Smith's contributions to CMSWire and he does a good job of presenting DAM concepts in a way that is straightforward for non-experts to understand. However, I disagree with a number of the points raised in his recent article, "Open Source DAM Solutions: More Control for Those Who Need It,"  as I believe it misrepresents this category of software license.

First, a disclaimer -- I work for a consulting company that uses open source DAM solutions that originally developed an open source DAM system that has, only recently, been spun-off as an independent business. We still maintain installations for selected clients and, therefore, we continue to have a commercial interest in it.

Open Source Defined

Edward's article does not offer an exact definition of what is meant by "open source" so there is no frame of reference to assess his points. With that in mind, there are two ways to consider open source software:

  1. As a brand/idea
  2. Or, a more precise definition about what you can expect if you use any software product with an open source license.

Taking the first route: in this sense, it means a software market segment composed of multiple vendors who view their support of open source as a positive trait that provides them with a marketing opportunity to acquire users.

They are eager to highlight points of differentiation with their proprietary competitors. Thus, various other elements get appended on to what you need to have to offer in order to be considered "real open source." These might include a free public download, active user community or specific type of development management structure.

While those could be considered desirable features by some, they are not, in themselves, necessary for the product to actually be open source. 

The second approach: You may or may not have needed to pay for a licence to become an authorized user, but the critical point that defines whether or not you have an open source product is if you are permitted unrestricted access to the source code used to create it. To do that, you should not have to pay a premium for the source code element, jump through legal hoops, coerce or threaten the vendor to hand it over. The code is part of the overall package that you were offered when you first decided to use the software.

The second definition appears to be clearer and more factual to me, so that is the one which I will refer to in this article.

Open Source Costs

As established, open source does not mean "free of cost." The article makes this point:

"With open source DAM software, you won’t be paying for licensing, but you will be spending more on consulting and training from internal or external resources."

Based on the definition above, this is premise is wrong, you might still be paying a licence fee for an open source product -- for a right to use it in other words. Also, the second point is unsubstantiated, you may end up paying more or less, for consulting or training.

How much depends on what exactly you require and the vendor's rates or other charging structure. You cannot generalize on pricing with reference to the licence alone since the costs applied depend on each end user's unique requirements and the vendor's individual cost pressures or profit objectives.

Open Source And Custom Development

The article follows up with this:

"Open source software provides a high level of control to companies that have invested in a development team"

I think that might be better phrased as "open source software provides a high level of control to companies that wish to adapt their chosen DAM system." You don't need a development team unless you want to adapt the product using resources you will be responsible for supplying yourself.

In the past, my company has deployed DAM systems for clients where the buying authority was from a non-technical department such as marketing and if customization was needed, we provided it for them. They did not need to organize that themselves. Other than a non-technical requirements specification that we provided for them to sign off, the details of the implementation were all our problems to solve.

If you are willing to pay the price they are asking, any vendor (irrespective of the licence) will usually customize the software for you. The only difference between open and closed source is that with the former you retain the option to handle that customization yourself.

Open Source Comes In All Technological Flavors

Edward says the following in his article:

"… what is your IT department’s operating system preference? An organization that embraces Linux is more likely to succeed with open source than a Windows-only shop because Linux distros and open source DAMs often share the same environments and tool-sets."

The DAM system we developed is entirely Windows based and uses .NET and Microsoft SQL Server. We chose those technologies because they are what most of our corporate clients were using and are preferred by many IT departments too. There are a number of other open source DAM systems available that use Java, which is also favorably received by most IT operations. Again, you cannot generalize a technology based on the product licence alone.

Open Source -- Cakes Or Cars?

Edward cites an analogy used by Theresa Regli of Real Story Group:

cake_shutterstock_64129402.jpg

"I learned a good analogy for this from Theresa Regli at Real Story Group: You can think of open source DAM like a recipe for a cake, and traditional DAM like a cake purchased from the bakery."

I've read several articles written by Theresa as well as heard her speak at DAM industry events and I tend to agree with a lot of what she says. With this one, I would say that open source is more like buying a cake where you get the recipe and ingredients printed on the side of the bag -- which isn't that remarkable and doesn't pose too much of a commercial problem for bakers either.

I'm not sure that the cake analogy is the best one on offer, however. Buying a DAM system is a "considered purchase" process that an end user will think about for some time. If it were like buying a cake, there probably wouldn't be a demand for DAM vendor evaluation reports of the type Real Story offer -- which there clearly is.

Another comparison would be to say that buying a DAM system is similar to purchasing a car. You're going to want to test drive it at least once, ask friends for their opinions, read reviews about the model you are interested in and generally "kick the tires" a bit before buying.

With a car, you can open the hood up and have a look at the engine and make modifications if you want to. Alternatively, you can take it to a mechanic of your choice if you don't fancy getting your hands dirty yourself. That might be with the dealer you bought it from originally, or it could be someone else.

Closed source software is more like having a vehicle where the hood is locked with a special custom key that only the manufacturer has copies of. If it goes wrong, you have to go back to them and they will appoint one of their employees or "authorized partners" who is then given the key and allowed to fix it for you.

Most drivers wouldn't tolerate those kind of restrictive practices from an auto manufacturer, it's a mystery to me why sections of the IT industry continue to get away with it for software.

Where Open Source Is Different

I'm going to pick up some business aspects of open source that are not covered in Edward's article.

In a corporate purchasing exercise, the end user's procurement department has to consider what happens if the vendor either goes bust or decides they are going to cease support for a given application.

There is a complex legal workaround for closed source software called a "software escrow agreement." This needs to be worked out up-front and involves the vendor depositing the code with an authorized third party -- the escrow provider. The submission has to be audited and checks carried out to make sure the full code has been supplied and will be usable later should the need arise.

If some situation occurs like the vendor goes bankrupt, the escrow provider is authorized to release the code to the end user. The escrow process is expensive and time consuming for all parties. These agreements are common in the public sector and also feature in larger private sector implementations too.

With open source software you can bypass all this because you legally have rights over the code already. It is one of the key reasons why this model offers major advantages for limiting your exposure to vendor risk as an end user.

The Cloudy Future Of Closed Source DAM

If you are using "on-premises" DAM system (i.e. installed internally to your own servers) and your vendor stops trading or decides to cease support of your application, it's obviously not good news, but you will still have some time to get a replacement lined up.

By contrast, if you are using a hosted or Cloud DAM then the time-frame isn't an indefinite, "until it stops working" proposition, but is set according to whatever duration the now reluctant vendor decides (or is able) to offer you.

Open source gives you some options to deal with this situation because you have the right to access the code and get someone else to set the system up for you elsewhere. It makes the Cloud a far less risky software delivery model as it has built-in protection already as a feature of the software licence.

Conclusion

It is my view that software applications should always come with the source code included. If you don't get the code, you're not getting the full package. That wouldn't be considered acceptable in other markets and it only persists in software because of an unchallenged historical precedent. It's about time that all changed now, especially as we gradually move towards a model for DAM software that is distributed across multiple suppliers and service providers.

Image courtesy of Elena Gaak (Shutterstock)

Editor's Note: To read the article that fired Ralph up, check out Edward Smith's Open Source DAM Solutions: More Control for Those Who Need It