Open Software versus Closed (Proprietary) Software

The project is a go. The decision has
been made. Because of the strategic nature, a significant investment
will be made to optimize and support a critical business function
with the development of new software.

For many a key question requires
answering, does the organization develop this new software in-house
or outsource it to a specialized development firm? Quite an array of
factors can go into deciding this question. In other cases, the
question might be simple to answer.

Increasingly however an additional
question comes into play when deciding how to move on the question of
software development, go with an open source solution or a closed,
proprietary solution? Open and closed systems, like anything else,
have advantages and disadvantages.

For example if software development is
done in-house proprietary software can provide legal protections for
any intellectual property built into the functionality of the
software that the organization considers critical to its great
business success.

On the other-hand. an in-house system
that either is developed internally and then opened or built
initially on an open source codebase can reduce development costs and
overhead.

These days, for many, the virtues of
openness has an strong appeal. Consider the example of a little
project I undertook a few years ago to connect an Apple //c to a Mac
mini. At the heart of the hardware connection is the bridge between
the old-school RS-232 standard to the currently ubiquitous USB standard. To many the success of the project is seen in the very open
nature of the two standards. While I was able to purchase all the
parts I needed, “off-the-shelf”, many, not doubt would note that,
if the key product didn’t exist, I could have taken to building my
own cabling, by looking up the published documentation on the two
standards.

But a standard, just like software,
doesn’t have to be open to be well documented. Now a days
the use of Microsoft Word or Excel goes without much forethought. If
considerations are made it is with the eye toward wide support,
compatibility and availability. Thus, while every organization,
software or individual might not be highly compatible with latest
version of Microsoft’s productivity software, the high adoption rate
means at least a high rate of basic support and compatibility for the
software and its document formats.

In fact, opened or closed, standard or
software, the importance for many is not about the technical or legal
risk. From a business perceptive, more than anything else, the question ends up being about support and compatibility.
If one invests a large amount of money into software to manage a critical business function the concerns and ideals of open
or close take on a lot less importance . What does take on
importance are questions about return on investment or on-going cost
to support, manage or improve upon the solution, in the short and/or
long term.

This is why people talk about communities, development networks, ecosystems and adoption rates. Because these pieces of information present a larger picture about market conditions. For if software and the standards the software adopts are largely adopted then chances are good for the long term viability of the software.

Market position and investment costs, also explain why, more times than not,
market leaders such as Twitter, will favor closed systems over open
ones whereas disruptive challengers, such as Oracle back in the day,
will champion openness over close-knit systems.¹ For if the “micro-blogging” format becomes an open standard then Twitter loses out on their investment scaling up their infrastructure. Whereas Oracle, with the open SQL standard, provided a challenge to the proprietary hardware/software lock-in of IBM, the success of their challenge directly dependent upon their investment in get SQL standardized with high adoption.

In other words the division between
opened and closed software is hardly as cut and dry as many try to
make it out to be.