Hardware, software and expert advice for digital signage and kiosks
 Home Products Solutions Blog Support Company News Contact
Customer Login 
Digital Signage Insider SignageWire
Latest Articles Full Article List

The Digital Signage Insider
WireSpring's blog featuring tips and analysis from a team of industry experts

Thinking of Writing Your Own Digital Signage Software? Read This

Author: Bill Gerba on 2010-03-31 10:50:00

During the past few weeks, I've run into not one, not two, but three companies who are considering writing their own digital signage software. From scratch. We noted this phenomenon several years ago, when investigating the make-vs-buy question for kiosks and digital signage networks. Frankly, I'm baffled that people are still thinking about writing their own platform here in 2010, given all the mature and affordable software packages that are available today. Without turning this article into a sales pitch, I'd like to talk about some of the arguments that I've heard from the do-it-yourselfers and hopefully set straight some of the widely-held misconceptions about what really goes into creating a digital signage software platform -- or any piece of software, for that matter.

Better, faster, cheaper. Pick... none?

I don't want to write an article about why you should buy my company's software -- or anyone else's, for that matter. Nor would I ever discount the quality or capability of open source and community-authored software. I use many such programs every day of the week, and they usually rival or top their commercial counterparts. But of the three companies I encountered who were contemplating the make-versus-buy, none are software companies, and two aren't even tech companies of any kind. One has a significant amount of digital signage experience. Another has a more modest track record in the industry. And one is still cutting its teeth on a prototype network. In all three cases, WireSpring's kit is being considered alongside a number of our competitors -- mostly good ones, with a few lackeys thrown in. (Even with over 330 companies in our competitor database, we come across one or two new guys each month.) In each case, cost is being cited as the chief factor in prompting the make-buy decision. In general, the cost-related arguments fall into two categories:


Image credit: Andrew Michaels
Fallacy #1: We can write it ourselves for less than the cost of [X software licenses / Y months of SaaS service / Z firstborn children]

Software companies are businesses, so yes, we do make a point of trying to sell our products to others for money. And while some firms seem adept at gouging customers with sky-high prices, most of us either start out honest, or else we're kept honest by our competitors. Still, there's apparently a notion out there that software development involves no capital expense and has no ongoing support costs. The reality (from my point of view, at least) is that good software developers are expensive. I hate to objectify them like that, because they can be pretty awesome people, too. But awesomeness doesn't show up on my P&L statements. Salaries do. For the cost of even an extremely modest, hypothetical development team -- perhaps 2-3 developers and a QA engineer -- you can buy a lot of software. And that doesn't even figure in tech support or take into account how long it would take said developers and QA folks to build a product that was actually usable.

Another big misconception -- and I can totally appreciate why anybody who hasn't worked at a software company would think this -- is that once you've written and released your perfect software version 1.0, you can fire your development staff, kick up your heels, and be done with it. I really, really wish that was the case. (Well, except for the firing part -- see the aforementioned note about awesomeness.) But a software program is never really "finished," and even great software demands a considerable amount of expensive, ongoing maintenance. What drives this need for maintenance? Here are a few of the gremlins that are bound to pop up:  
  • Discontinued hardware: The playback hardware you install at your sites (whether it's a PC or an embedded device) will eventually be discontinued and replaced with a new model, forcing you to update the operating system, integrate new drivers and re-test hundreds of scenarios before you can deploy on the new hardware.

  • Security patches: Mandatory security patches for the underlying operating system (whether it's Windows, Mac OS or Linux) or the other programs you use on there will interfere with your existing playback tools, forcing you to re-write those tools to be compatible. Internet Explorer has been notorious for this, with even a small change in the IE security model requiring major changes to digital signage playback tools that rely on IE for showing any type of web-based content.

  • New content formats: Your customers will eventually want to display new content formats that didn't exist when you first wrote your playback software, requiring you to integrate new codecs or upgrade the existing ones.

  • Browser updates: The web browsers that your employees or customers use to access your management portal (whether it's hosted in-house or out on the cloud) will be updated to new versions, forcing you to update your HTML, Javascript, and other code to be compatible with the new browser releases.

  • Bug fixes: No matter how much you test before releasing a software product, some number of bugs will crop up once it's in the field -- and it can sometimes take years before a given bug shows up. Like it or not, you'll probably be issuing bug fixes for the life of your product.
These scenarios may be specific to the digital signage industry, but the same general issues apply to all software development projects. In fact, companies like Microsoft, Apple, Adobe and Symantec are all constantly updating their legacy products, keeping a veritable army of developers and quality assurance staff employed in the process. But they have millions of clients over which they can spread their costs. When you write your own software, your first, biggest and only client is you. You get to pay 100% of the cost of every new feature and every bug fix. And instead of having a predictable, known cost for what you'll pay every year for keeping things up-to-date, writing your own software means that you bear the entire risk that those endeavors will be more expensive and time consuming than you expected.

Fallacy #2: We have elaborate, complex and unique requirements that need to be designed from scratch

If you really, really wanted a teal and fuchsia zebra-striped car, would you buy a car and get a custom paint job, or would you get an engineering degree and redesign the internal combustion engine? I have a slightly more diplomatic way of phrasing this when talking to potential customers. But what it boils down to is that when taking a from-scratch DIY software approach, you will be spending time and money solving problems that others have solved already. And I can tell you from experience that even seemingly simple tasks -- like reliably moving a file from server A to player B, or getting said file to play smoothly from beginning to end unattended -- turn out to be pretty complicated when they have to work in the real world, and not just in your development lab.

At the same time, I understand that all businesses have unique requirements, and some might have enough complexity to warrant writing software to automate (or at least improve) those processes. But in my book, that just calls for a good API and some engineering cleverness. I can't think of many real-world cases that would warrant a rewrite of what is basically the digital signage industry's equivalent of the wheel.

Perhaps you've done the math and considered salary expenses, time-to-market delays and opportunity costs, and you still think DIY software is a good idea. In that case, you're either planning an extremely huge network with remarkably unique needs, or you're underestimating some part of the DIY proposition. That sounds like a harsh conclusion drawn by a biased party, and maybe it is. But given how many do-it-yourselfers have become our clients and the clients of our competitors over the years, I've noticed a clear trend that goes like this: (1) Meet new prospect doing make-buy analysis. (2) Prospect chooses "make." (3) Wait 2-3 years. (4) Get new call from old prospect looking to retrofit old network. (5) Repeat. This cycle is costly for everyone and ultimately limits the growth of our industry, as otherwise promising network owners spend their time re-inventing the wheel, instead of expanding their networks and creating compelling content that achieves real business goals. Hopefully this article will help some of those people ask the right questions and understand the true costs of writing their own digital signage software, and enable them to make the best technology decision for their business. And if not... Well... I'll see you at step (4) then!

Comments (20)

Subscribe to comments for this article | Trackback

2010-03-31Stephen Randall writes:
This post should be mandatory reading for anyone wanting to enter the digital signage marketplace.
2010-03-31Bill Gerba writes:
Thanks, Stephen. I'm sure this is a shared pain :)

I just hate to think of the time and money being wasted re-solving solved problems. As if our industry didn't have enough pitfalls and caveats already!

-Bill
2010-03-31Lionel Tepper writes:
Excellent article! One of your very best to date.
2010-03-31Rob Gorrie writes:
Of our 100 partners, many many use proprietary code.

I will support the above that buy is better than build at this period in DOOHs maturation and comment that a time is coming in ad standardization and auditing that will require and demand either an accredited, audited system to be playing the ads/content or a vigorous audit of the proprietary system that will be taxing on internal, self-made dev teams and ops departments.

The existing vendors will be on top of or involved in the ongoing standards/advertiser/retailer needs and will be ahead of the curve on this front. Standalone systems will not and you will constantly be playing catch up.

Just my 2 cents

RG
2010-03-31Social comments and analytics for this post writes:
...This post was mentioned on Twitter by billgerba: This week's rant: "Thinking of Writing Your Own Digital Signage Software? Read This!" at Digital Signage Insiders: http://bit.ly/cMX2d7...
2010-03-31Bill Gerba writes:
Lionel: Thanks!

Rob: I understand that lots of people use some proprietary code. Stuff for integrating with other CMS or NMS packages, making and testing elaborate schedules, etc. will always involve more business rules than any DS software provider can cram into their generic offering. But there's a big difference in my mind between bolting something on to an existing playback platform like FireCast or Scala, and writing that playback platform from scratch.

In the end it's untenable. Can you imagine if some network decided that they didn't like MPEG, so they were going to write and use only their own video codec?
2010-03-31Pat Hellberg writes:
Wow. This is still happening?
Don't stop at writing your own open-source DS software. Why don't you churn your own butter, sew your own clothes and conduct your own brain surgery? Think of the savings!
Guess we have to dust off the Clint Eastwood quote that we used in a previous blog entry, "A man's got to know his limitations."
2010-03-31Rob Gorrie writes:
Bill:

When I say many of our networks are running proprietary code I mean built from the ground up full systems...not just pieces of.

And yes, it is untenable to continue like this.
2010-03-31Darren Coles writes:
We all look at the differant ways of doing things. Software development is an art and should be left to the experts. In our research for Digital Signage Software we tested everything, from Open Source that we could take the core and enhance to off the shelf commercial software. And the desicion was easy; for when we found a solution that had an extensive API set, which ment we could concertrate on the intergration and applications that clients are paying for and not worry about the stability of the core software. Bill I read your articles often, and this is one of the better ones.
2010-04-01Lyle Bunn writes:
Totally agree Bill. "The biggest cost of an project is the mistakes".

Starting with a stable media management platform of suitable functionality mitigates the risk.

It also allows better cost and timeframe management.
2010-04-01Stephen Ghigliotty writes:
Another great post Bill...

I sat through a pitch about a year ago with some well funded developers who were looking for their first beta users and I couldn't help but think it was too late even then. Unless you need something quite custom, I cannot fathom a rational "write your own" software strategy in 2010.

From my experience only a fraction of the capabilities are typically deployed by most digital signage network operators. We would all be better off if network operators focused on compliance, network performance and effective content delivery.
2010-04-01Tim Burke writes:
Well Said.
I saw that one of our competitors was writing their own code at a recent show. My friendly response to them was along the lines of OMG! Are you nuts?

I heard someone at the DSA state that they estimate there to be over 300 DS management tools in the marketplace. That number feels high to me, but I'd say at least 100 - 150. Crazy to add more to the marketplace. We VAR several different software apps because we knew we didn't want to "go there". We have great offerings, each with their pros and cons and can recommend the best solution to clients based upon their needs. As it should be.

Tim Burke - @KioskGuy

See you all at the KioskCom & Digital Signage show in April 2010
2010-04-01Bill Gerba writes:
Glad to hear I'm not the only one surprised by this, though the commenters here are pretty much the "usual suspects" of our industry.

Tim: Per the 300 DS software guys number, we have an internal database of 330. It's been at about that number for nearly a year (between additions and deletions), so I think it's pretty accurate. And it doesn't include many products that haven't ever been marketed in English, so in fact the global number is probably somewhat higher.

All that wasted and duplicated effort. Sigh.
2010-04-06Lyle Bunn writes:
Additionally, the pace and directions of Digital Place-based Media have got to have everybody thinking beyond their own network. Assuring that future interconnectivity and interoperability are built into the software application is the challenge. Each media management software serves as part of an industry-wide platform and weak foundations make for a vulnerable industry and unconnected silos of networks.
2010-04-08Tim Warrington writes:
I do think we need some new software developed, but all the digital signage software wanna bees keep building the same old software. The digital signage software need to get better, more dynamic, when i was in the show i new what the weather was like in every part of the world.
2010-04-08manolo writes:
Bill - good post, and its easy to see that it was written from the perspective of a guy who's developed his own software. Admittedly, I too had my own proprietary solution in 2000, which I then migrated my client to Wirespring in late 2007. While I do agree with the points you raised, I don't agree that we should rally around to convince others from trying to build their own, true innovation comes from competition and people who think they can build the better mousetrap. I'd hate to imagine a world where someone convinced Bill Gerba not to make Firecast. Perhaps We'd all be on Scala right now :)
2010-04-20Josua Hönger writes:
I enjoyed reading the article. There is so much truth in it!

However, there is always the exception to the rule.

2 Years ago we decided to go the DIY way and we started to develop our own solution. We had a hard time until we got some of the base things like 100% fluid playback of full hd videos, no delays or black frames between adverts, mixing content of different types (e.g. crossfading videos with flash-webpages) etc. From beginning on, we hired true developer cracks, far beyond the average developers that just pass university.

We don't regret it at all. Today we have a player that easily challenges each other player we know of in the whole industry of digital signage in terms of features, quality and price. Wherever we show it, we earn disbelieving looks.

In fact we are so convinced and confident about our achievements that we changed the business model from being an integrator to being a partner and solution provider of integrators.
2010-05-07Michael Marcus writes:
Great article Bill. With the diversity of product offering available (both in terms of price and features) there really is no good reason for users to start the slide down the slippery slope of "I'll make my own".
As you so correctly point out, they'll find that they're so busy maintaining/ bug fixing the "simple" software, that their core business suffers.
Basic business rule #1: Don't custom-make it if you can buy it off the shelf!
2010-07-01Sergey writes:
Agree with the author that the development of software is not so easy and not so cheap as it may seem. For example SDB Complex - Software for Digital Signage and Indoor TV, design c 2002 to the present day.
By the way not often someone to develop their own software, for example, the SDB Complex currently operates 46 companies.
2010-08-18digital signage software writes:
Great advice. It has really helped me to produce my own digital signage software. Thanks.

Leave a Comment

Name:
Email Address:
(required but won't be shown)

Website:
Comment:
(max 2000 characters)
Are you a human? If so, uncheck this box:



Digg this! | Del.icio.us


Previous Article: Shopper Marketing: Q&A with Saatchi X's Dr. Christopher Gray
Next Article: Digital Signage Content Creation: Grabbing the Low-Hanging Fruit

Front page of Digital Signage Insider Blog

LEGAL STUFF: The Digital Signage Insider is written by multiple authors. The author of each article is clearly identified at the start of the article. The opinions expressed in each article are solely those of the author, and do not reflect the official opinions of WireSpring Technologies, Inc. All articles are copyright © 2004-2009 by their respective author. All content besides the actual article text, e.g. surrounding branding and informational content, is copyright © 2000-2009 WireSpring Technologies, Inc. All rights reserved. Except as provided in WireSpring's Republishing and Syndication Policy, no articles may be reproduced, in whole or in part, without WireSpring's express written consent.

Subscribe to our RSS feed


  Subscribe via XML/RSS/RDF

About this blog and our team
WireSpring provides hardware, software and services for digital signage and kiosk projects. But this blog is a labor of love. Our posts cover everything from case studies to creative briefs, and we post new articles several times a week.

The blog team:

Our blog team includes some of the industry's most well-respected leaders:

Founder and Senior Writer:
Bill Gerba

Editor:
Jeremy Zaretzky

Writers:
Gary Halpin, Agency 225
Pat Hellberg, Kaicon
Hercules Huggins, WireSpring
Dr. Alice Julier, University of Pittsburgh
Darren Kubel, WireSpring
Christie Liu, Strategy Institute
Graeme Spicer, Adcentricity
Axel Vera, Infusion Marketing
Roberto Vogliolo, Artexe

If you would like a member of our blog team to provide feedback for a story you're working on, or you want them to speak at your event, please contact us.

Editorial policy:

Article topics are selected by our writers and editors, with the goal of providing objective and useful information to the entire digital signage industry. This means covering a lot of projects that have nothing to do with WireSpring's products, and we're fine with that. Whenever we mention a project that WireSpring is directly involved in, we'll be sure to provide appropriate disclosure in the text. If you'd like to suggest a topic for a future article, feel free to leave a comment or contact us. We don't take very kindly to PR spam, so please review our past articles before contacting us to verify that what you're planning to send is a good fit for our audience.