A Bazaar Fable

Copyright (c) 1999-2001 by Rich Morin
published in Silicon Carny, February 1999


I'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' Tk module (aka perl/Tk and pTk) solves this issue nicely for Unix Perl (www.perl.com), but it isn't available for MacPerl (www.ptf.com/macperl).

So, I was quite pleased to hear, recently, of a very promising hack. The fine folks at the Qub Group (www.qub.com/group) had written a pair of scripts (one in Perl, one in Tcl) that would allow Perl to use Tcl/Tk (www.scriptics.com) as a GUI server. Hot Stuff!

Unfortunately, the scripts were only advertised as working under Unix and Windows. Looking at the code, however, I felt sure that one of the MacPerl hotshots would be able to patch things up. So, I posted a query on the MacPerl list.

Within a day, Chris Nandor (pudge.net) responded, giving 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 semi-colons and "\n" codes). If I were 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 was covered by the GNU General Public License (www.gnu.org), I didn't need anyone's permission for 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 Unixish programmer would not need to know that any changes had been made; a Mac programmer would not 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 pieces of email. The folks on the MacPerl email 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 perl/Tk with WishPerl, yielding a totally Perl-based solution. The brute- force approach would layer perl/Tk on top of PerlWish; it might be cleaner, however, to merge the two packages in some manner.

Either solution, however, would be portable, require little or no maintenance, and be feasible for me to write (with a little help from my friends). So, I suspect that it will happen...

The Moral(s)

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 that the code was small and abstract, greatly easing the conversion effort.

All of this fits in with a comment that John Gilmore (cygnus.com/~gnu) made about "Reducing the transaction costs of co-operation":

This is what free software does. When the published copyright terms of intellectual property permit anyone to modify or improve it and re-distribute 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 not insignificant; Microsoft acknowledges it in their "Halloween Documents" (www.opensource.org/halloween.html). 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.

Everone was a winner, because nobody had to donate more effort than they could spare. Many, many folks have contributed to the underlying tools: MacPerl, Perl, Tcl/Tk, Tk/Perl, 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 does not need to be a Larry Wall (Perl) or John Ousterhout (Tcl/Tk) to make a useful contribution! For more information on how you can get involved in Open Source use and development, see the GNU Project (www.gnu.org) and Open Source Institute (www.opensource.org) web pages.

About the author

Rich Morin (rdm@cfcl.com) operates Prime Time Freeware (www.ptf.com), a publisher of books about Open Source software. Rich lives in San Bruno, on the San Francisco peninsula.