Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Mark Leighton Fisher (4252)

Mark Leighton Fisher
  (email not shown publicly)

I am a Systems Engineer at Regenstrief Institute []. I also own Fisher's Creek Consulting [].
Friday May 30, 2003
04:05 PM

Productizing Software and Open Source

[ #12526 ]

Sometimes it is just too much bother to productize software you have written (i.e. turn the software into a marketable product). As an example, Micro Data Base Systems in the early 1980's needed a better office file transfer system than sneakernet, so Tim Stockman wrote a program for file transfers over serial lines that was significantly better than the XMODEM etc. programs available at the time (making our file transfers through the central serial line switchbox very convenient for that time). However, serial line file transfer programs were far away from the MDBS stock-in-trade of PC databases, so the program stayed in-house. This is one example of where making a program Open Source would have benefited the whole software community including the original author's company.

Turning software that is already written into a product requires a whole host of activities, ranging from market studies to graphical package design to CD reproduction. These activities are not needed for Open Source software. The only added step needed after the Open Source software is tested, working, and documented is to place the software out on a reliable repository.

Most software is written for in-house use, irrespective of whether other entities could make use of that software. IMHO, making such software Open Source when:

  • There is no clear competitive advantage to keeping the software in-house (a counter-example could be automatic stock-trading software at a brokerage, as this would embody trade secrets of the brokerage); and
  • The software has some general utility rather than being specific to the company in question;

makes a lot of sense to me. Most businesses are not in the retail software market (RCA (consumer electronics), Eli Lilly (pharmaceuticals), Tyson (chicken), etc.). But metric boatloads of software is written by these companies, much of which does not contain any trade secrets but is generally useful. This software could be made Open Source, thereby providing additional developers/testers/documenters to the entity without costing the entity more than the time required to make the software suitable for Open Source distribution. Although time is required to process in-house software into a form suitable for Open Source distribution, this could be paid back by the efforts of those outside the entity who are using the software and improving it, reporting defects, etc. I have yet to see an in-house software development department that has enough staff to implement every requested improvement.

The process of turning existing in-house software into Open Source software has the advantage that the software will already be written, documented (some), and working, whereas many current Open Source projects do not have enough resources to get to the point where they have written and working software even when the software is not documented.

Most software was never destined for the retail shelf, but has clear general utility without giving significant competitive advantage to the entity that created the software. If that software was made Open Source, (again IMHO) there would be benefits to both the original authoring entity and the software community as a whole.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • That is... (Score:2, Interesting)

    ...the essence of the principle we apply at Fotango []. While we do hold code that we would not release, there large majority of code we produce is open sourced for at least the reasons you presented.

    At the very heart of economics of this, the software is often a loss-leader. We must produce the software in order to accomplish our business objectives. However, the software itself has no value other than the time that was spent writing it. Companies do recognize this, which is why the IT function of a com