Open Software versus Closed (Proprietary) Software

| 0 Comments | 1 TrackBack
| | | |

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.1 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.



1 It also explains why some companies, such as the Oracle example, might change their position over time, while others, like Microsoft, might have conflicting positions depending on the goals of a specific department/product.

1 TrackBack

TrackBack URL: http://pdw.weinstein.org/mt/mt-tb.cgi/156

I've been thinking a lot about software development and strategic business strategies recently, in part because of some business work I've been doing recently and in part because the reason why the software program exists has a strong relation with... Read More

Leave a comment

About the Author

Paul is a technologist and all around nice guy for technology oriented organizations and parties. Besides maintaining this blog and website you can follow Paul's particular pontifications on the Life Universe and Everything on Twitter.

   
   


Subscribe:
Add to Google Reader or Homepage
Add to My AOL

Add to netvibes
Subscribe in Bloglines
Add to Technorati Favorites

Powered
CentOS
Apache
MySQL
Perl
Movable Type Pro