Wednesday, August 31, 2005

Law and Economics and Code

My most interesting class by far this semester looks to be Law and Economics. Today, the professor used government-imposed minimal standards for apartments as an example of how interference with the market leaves both buyers and sellers worse off. Economics 101 teaches that when sellers costs are increased like this, the price of the product will increase, and consumers that believe those features are worth the extra money will get what they would have paid for anyway, while those that don't will be forced to spend money on something they would have rather spent on something else.

As a liberal free software geek, I'm torn about where to side on these kinds of issues. My liberal instincts nudge me toward feeling that this argument incorrectly assumes that local apartment markets are efficient; in my experience, there can be an extremely large range in the quality and price of urban apartments, enough so that what seems like one market of 60 landlords can actually be more like 20 markets of three landlords offering different kinds of products. And this isn't a response just to the apartment problem; trends like the skyrocketing pay of corporate CEOs, the increasing domination of American retail industries by a single provider (Walmart/Starbucks/Blockbuster), and the increasingly obvious effectiveness of corporate lobbying all point to an American economy that sits far, far from perfect efficiency, and which cries out for protection from monopolies.

At the same time, free software actually provides a powerful example of the productivity of markets that are governed purely by supply and demand (as Paul Graham has recently written), once you're willing to think of developers as consumers who are trying to decide where to spend their coding talents/time. Given the freedom to work wherever they think their time is best spent, as opposed to where supervisors/executives/Microsoft think their time is best spent, amazing increases in productivity are possible (not that I think the primary value of open-source is in its development methodologies, as ESR does... but there's no denying that its development methodologies are efficient).

So should authorities interfere in the activities of the little people? Based on the above, I'm half-tempted to answer, "Yes, unless the little person is me." But the real solution, unsuprisingly, probably lies in the GPL, which does place restrictions on developers, in exchange for certain protections. But extending the analogy that far will have to happen some other day.

Tuesday, August 30, 2005


So, I put out another significant release of the clip art browser today. As always, the damn thing took three times as long to write as I expected. For some reason, my personal projects always take an unexpectedly large amount of effort, and my school projects always take an unexpectedly small amount (which is good, since I generally start them as late as possible). Anyway, here's a screenie.

If you're wondering why your version doesn't look as incredibly cool as mine, its because you're not using the awesome Gartoon icon set, and (less likely) because you're not using Clearlooks (which happily will be the default theme in Gnome 2.12).

Speaking of advances on the Linux desktop, I'd be cautious about running the browser if you've got an older version of librsvg... I had major crash problems when I ran it with librsvg 2.8.1. Right now I'm using 2.11.1, which is relatively stable (with the exception of the office/telephone category of the latest OCAL... some image in that one folder causes the whole thing to die on my machine), but I've had the best luck with 2.9.5... I tested for a while with it a few days ago, and couldn't cause any big problems. Occasionally librsvg won't be able to render an image, of course, but as long as it doesn't cause the whole app to crash, the browser will notice that and try to render with another renderer instead (if you've told it to in the config file).

What's next? Documentation (somehow, that's always next...), a more powerful configuration dialog, a convenient windows installer (using py2exe and Innosetup), the implementation of some performance gimmicks that are already hinted at in the code, a gui for downloading and extracting the latest OCAL release, and, hopefully, work on the server side of OCAL as well, if I can ever bite the bullet and learn Perl.

Wednesday, August 24, 2005


I'm releasing version 0.32 of this project, which is now called the Clip Art Browser. Get it from

This is largely a bugfix release. Changes include:

Copy-paste works- sort of. You can copy-paste into the GIMP, but not into Inkscape. For now, I'm assuming this is an Inkscape issue.

The script has had a number of improvements, including a "-c" option to update the configuration file automatically, a "-h" help flag, better error messages and smarter placement of the output index file.

The localocal index file can now be placed anywhere, which helps to avoid permissions issues that had cropped up before.

The partial dependency on pyxml has been removed. The code doesn't need pyxml at all (for now... its very concievable that it might become needed again in the future).

Jon Phillip's cool Makefile has been included, but I need to update it based on these latest changes.

Dependencies are Python 2.4, GTK 2.6 and PyGTK 2.6.

To install, make sure you have a recent OCAL release extracted somewhere on your system. Then, extract the package and copy the contents of the clipartbrowser directory into your Inkscape extensions directory. Copy the clipartbrowser.conf file into the .inkscape directory in your home directory. Then run "python -v -c -f ~/clipartindex.dat DIR" where dir is the root directory of your OCAL dump. That should do it.

Saturday, August 20, 2005


I've released version 0.31 of the Clip Art Navigator. Its available at

There's plenty of changes in this version, but the coolest, to me, is that I was able to drop the requirement for an embedded SQL database for indexing local clipart (before, I'd been trying both SQLite and Gadfly), instead just using Python's own built in datastructures and pickling format. The net result is no dependencies on 3rd party libraries (for the searching code... the interface still requires PyGTK, since the python devs refuse to drop, or even make plans to drop, the albatross of tk) and lightning-fast searching (at least, 5 times faster than SQLite by my benchmarks).

The major issues outstanding now are the awkward procedure for indexing local clipart (I need to make a GUI), copy-paste functionality, and, somehow, figuring out a sensible visual interface for browsing OCAL by category. This last one will be particularly troublesome, since I designed the Clip Art Navigator to search multiple repositories simultaneously, and that's difficult to recconcile with the metaphor of the single category tree provided by OCAL.