Stories
Slash Boxes
Comments
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 ]

samtregar (2699)

samtregar
  (email not shown publicly)
http://sam.tregar.com/

Journal of samtregar (2699)

Sunday September 15, 2002
05:24 PM

On Open Source

[ #7741 ]
I'm a big fan of open source development. My entire career and much of my free time have been spent using and producing open source software. But I have my doubts that open source is right for every application. I was recently asked if I thought my company should plan to release a new project as open source. My immediate reaction was no and I then found myself floundering to explain lucidly why not. I'd like to try to do that now.

I've had good open source experiences and bad ones. My good experiences have been almost solely in releasing Perl modules on CPAN. My best CPAN efforts share a few notable traits - they're simple, they meet a reasonably common need and they do so in a flexible and efficient manner. These modules have been used by numerous people in a variety of situations. Their generous feedback has radically enhanced the utility and functionality of the code. In short, developing for CPAN has been a completely positive experience.

My bad open source experiences have centered around full applications; I've released a few and been involved in the development of others. Now, at the time of their release I've always thought they had the right characteristics to be successful open source projects - they met a common need and they were as flexible and efficient as I could make them. However, the positive responses have generally been minimal or non-existent. Some people did try to use these programs, but their reactions were rarely helpful. I'm not entirely certain why this is. Perhaps it has to do with the target audience; Perl modules are used by the same people that can contribute positively to their development. Or perhaps its just that creating an entire application is an order of magnitude harder than module development.

Creating open source software has costs. There are bottlenecks in open source development that just don't exist in an internal project. Of course, there are also huge benefits to be gained, not the least of which being the prospect of free labor. In my experience a failed open source project results in a large loss in time and energy. The question then is to determine whether a given project has enough of a chance to become a successful open source project to offset the cost.

In the case before me at the moment, I don't believe it does. The application will be a large-scale development to create a critical piece of business architecture. It meets a general need among similar businesses, but there is good evidence that businesses tend to solve this problem in radically different ways. My judgment is that the costs associated with making the system flexible and general enough to be released publicly would be unlikely to be repaid. Certainly some would attempt to make use of the software if we released it but my guess is that we would be unlikely to be successful enough to repay our efforts.

Instead, I favor releasing pieces of the project as modules on CPAN. Every time we recognize a solution to a general problem we should take it as an opportunity to lop off a new module. By focusing our efforts on this goal during the design of the project I hope to devote a significant portion of our development time on open source modules. In the end I believe this will be both more beneficial to the Perl community and more efficient than releasing the entire body of code would have been.

-sam

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.