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:

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!