A bazaar fable
Lessons learned from a Perl hack
Rich's recent experience with a Perl hack has him singing the praises of open source. (1,000 words)
'm a big fan of Perl, using it on both Unix and Mac OS. In general, I have little trouble porting my Perl code between the two systems. GUI code, however, has been a bit of a problem. Nick Ing-Simmons's Tk module (aka PerlTk and pTk) solves this issue nicely for Unix Perl, but it isn't available for MacPerl.
So, I was quite pleased to hear, recently, of a very promising hack. The fine folks at the Qub Group had written a pair of scripts (one in Perl, one in Tcl) that would allow Perl to use Tcl/Tk as a GUI server. Hot stuff!
Unfortunately, the scripts were advertised as working only under Unix and Windows. Looking at the code, however, I felt sure a MacPerl hotshot would be able to patch things up. So, I posted a query on the MacPerl list.
Within a day, Chris Nandor (coauthor of MacPerl: Power and Ease) responded with a pair of one-line hacks and some useful setup instructions. I tried this out and was very pleased to find that I could make it work.
I then started looking at the scripts to see what I could learn. I saw, as expected, that the Tcl code was being formatted as a string. I wasn't too happy, however, with the way the author formatted the strings (long lines with embedded semicolons and "\n" codes). If I was going to use this as a tool, I wanted the embedded Tcl code to look as "Tclish" as possible.
So, I started hacking around a bit. Since the code is covered by the GNU General Public License, I didn't need anyone's permission to do this. Fortunately, Eugene Skepner (WishPerl's author) was happy to help me with my effort, contributing a small fix that allowed things to work more smoothly.
Meanwhile, we all conferred on the cleanest way to integrate the Mac tweaks into the distribution. Chris did most of the heavy lifting on this (no surprise to me!), but the result was nice and clean: a Unix programmer wouldn't need to know any changes had been made and a Mac programmer wouldn't need to add anything special to use the scripts under Mac OS.
The entire process took less than a week and involved perhaps a dozen e-mail exchanges. As I write, the folks on the MacPerl e-mail list are happily playing with the new interface, scripting up singing jukeboxes and other fun stuff.
Meanwhile, I'm still toying with the idea of doing a quick-and-dirty port of PerlTk to Mac OS. PerlTk is a popular way of doing GUIs in mainstream Perl; this would allow me to port PerlTk-based scripts to MacPerl.
Doing this port the hard way (in C) is out of the question for me. It's too much like work, requires knowledge of Mac OS programming, and would be a maintenance headache. (I'm not into pain!)
I should, however, be able to combine bits of code from PerlTk with WishPerl, yielding a totally Perl-based solution. The brute-force approach would layer PerlTk on top of PerlWish; it might be cleaner, however, to merge the two packages in some manner.
Either solution, however, is portable, requires little or no maintenance, and is feasible for me to write (with a little help from my friends). So I suspect it will happen.
Several factors were critical to the success of this fable. Because the software was open source, I was able to examine and modify it. The Internet allowed us to exchange information over long distances with negligible effort. The use of scripting languages meant the code was small and abstract, greatly easing the conversion effort.
All of this fits in with a comment John Gilmore made about "reducing the transaction costs of cooperation":
This is what free software does. When the published copyright terms of intellectual property permit anyone to modify or improve it and redistribute it, there is no transaction cost for people to do so. When the terms disallow these things, anyone who wants to do them must negotiate with the owner. This takes energy and time; most people never bother, so most improvements never get made. Often the improvement is small, like a corrected paragraph in a book, a bug-fix in software, or smoothing out a user interface glitch. Transaction costs must be very low for these kind of cooperative improvements. But the impact of hundreds of small improvements is a substantial increase in quality and function, which is quite hard and expensive to duplicate in uncooperative environments.
The power of this kind of cooperation is hardly insignificant: Microsoft acknowledges as much in its so-called Halloween Documents. Even in this trivial exercise, the benefits are clear: I would have had great difficulty in making the changes Chris and Eugene supplied; they made the necessary changes with ease.
Everyone was a winner, because no one person had to donate more effort than he could spare. Many, many folks have contributed to the underlying tools: MacPerl, Perl, Tcl/Tk, etc. Now all of us can benefit from (and rely upon) their presence.
My contribution, in this small example, was to notice a small gap -- something useful that the tools could almost do. The other contributors had never applied their skills to this particular problem until I drew their attention to it. Once they looked at the problem, it was trivial for them to solve.
As this example clearly demonstrates, one doesn't need to be a Larry Wall (Perl's creator) or John Ousterhout (Tcl/Tk's creator) to make a useful contribution! For more information on how you can get involved in open source use and development, see the Open Source and GNU Project Web pages, linked below.
About the author
Rich Morin operates Prime Time Freeware (www.ptf.com), a publisher of books about open source software. He lives in San Bruno, on the San Francisco peninsula. Reach Rich at email@example.com.
If you have technical problems with this magazine, contact firstname.lastname@example.org