ecently my company, Desaware, decided to release the source code for our component products?and in doing so found ourselves suddenly directly involved in the open source vs. closed source debate.

I suppose it’s not surprising?along with privacy and intellectual property rights, open source will be one of the defining debates of this decade, the results of which will impact each of our careers (not to mention the profitability of corporations like Microsoft).

It’s likely to disappoint ideologs on both sides of the open source debate, but I must confess that our reasoning for releasing source code was about as far from ideology as you can get. We did it, simply, because that’s what customers wanted. Or to be specific?over the past year we found increasing numbers of potential customers walking away simply because they would not, or were not allowed to, use third-party components at all.

The customer, of course, is always right. That doesn’t always mean that what they believe makes any sense. The economic arguments in favor of using components are overwhelming?a few hundred dollars often buys you functionality that would cost many months and thousands of dollars to duplicate. So what can these people possibly be thinking, that they would walk away from such savings and simply refuse to use components at all?

Ultimately, it comes down to two major reasons: First, a preference many programmers have to do it themselves (because it’s more fun, justifies their existence, etc.). Second, because these developers and their companies simply do not want to be dependent on anyone for their mission critical software. Bad enough that they’re dependent on Microsoft (there are uncountable VB6 developers today caught between the rock of high cost to port existing VB6 code to .NET, and the anvil of Microsoft’s inevitable dropping of support for VB6), but to be dependent on a third-party software vendor is unbearable. And size isn’t the issue here?during the recent economic downturn, the streets of technology parks were littered with the debris of large and small companies alike.

I don’t have much to say to those who insist on building their own solution just for fun when there are component solutions available?at least not much I could say in polite company. Evolution will be their ultimate judge.

But how does one answer a justifiable concern for long-term support? Contrary to “end of life” policies of many software companies, the true end of life of any software is when the last customer stops using it. And the fact that we as software vendors often refuse to accept that is nothing to be proud of.

The Ultimate Security Blanket
Providing source code is one answer. It’s the ultimate security blanket. You buy it, bundle it up with the other build tools for the application, stick it in a box labeled “for emergencies only,” and shove it in a corner. Five years, 10 years, 15 years from now, when you suddenly have to make that one critical fix or rebuild, instead of facing the expensive or impossible task of recreating the application from scratch, you face the still expensive, but manageable task of recreating a build environment and fixing the problem.

The fact that you didn’t write the original source code doesn’t matter?even if you had built it in-house, the person who wrote the code would probably be long gone anyway. Having access to the source code makes using a third-party component no more risky than building your own.

Software vendors don’t like to talk about risk. What company does? But we need to talk about it. If there’s one thing the recent recession has taught us, it’s that no company is immune to mergers, reorganizations, or total collapse (all too often with executives being carted off to jail, an extreme that mercifully has not, to my knowledge, happened in the component industry).

When I worked as a hardware engineer, my company had a firm policy?we couldn’t specify any component that didn’t have an alternate source. Alternate sourcing and cross licensing are extremely common in the hardware world. On a personal and corporate level we aren’t afraid of buying desktop computers from small companies because we know that if it fails, we can always get a drop-in replacement from somewhere else. Same goes for hard drives and other components.

But there is rarely an equivalent in software (actually, the different distributions of Linux could become the software equivalent of alternate sourcing for operating systems?a fact that undoubtedly worries Microsoft). Providing source code is the only answer?it’s a way to say to the customer that if worst comes to worse, they can be their own alternate source. Even Microsoft has demonstrated this by providing Windows Source to certain customers, like large governments, who have the leverage to demand it. And, yes, escrow services should be sufficient for this purpose, but for some reason most customers don’t like that approach. Perhaps it’s lack of confidence in the long-term viability of the escrow services themselves? Or perhaps lack of faith in their own institutional memory to recall that such escrow arrangements had been made.

There are some nice side benefits of having source code available: the ability to learn from someone else’s code, and the possibility of customizing components to suit specific needs, but those are smaller issues. Security is always a concern, but it is only applicable to software that has the potential to elevate the privilege of a user?something that applies to a relatively small number of software components.

Releasing source code posed a huge dilemma for us, as a company. What about software piracy? What if someone tries to resell our technology as their own? In fact, there were so many complex issues that we juggled that I decided to write a whitepaper with the impressive title, “Impact of Source Code Availability on the Economics of Using Third Party Components” (get it at www.desaware.com). The whitepaper started out as a way to get our thoughts in order with regards to the tradeoffs. Ultimately, two factors were decisive in our choice to release source. First, we have an expectation that an increase in sales will offset any potential loss due to piracy (a loss which exists to some degree regardless of source availability). Second, it really is the right thing to do for our customers. Of course we also took one other action that we really didn’t like: We paid a high-priced intellectual property attorney to write a licensing agreement that defines the terms under which the source code can be used.

So what about the great closed source vs. open source debate? I’m never one to shy away from controversy, but that’s for another time and place. What we did by releasing our software was not open source by any stretch of the imagination. Our source code is licensed to individual developers for their own use?not for distribution. Does a true open source model make sense for the component world? I don’t know. What I do know is that source code availability provides a level of peace of mind for some developers that probably cannot be matched any other way.