Sometimes there just aren't enough hours in the day. This is a list of my projects which have not been updated for a long time, and I don't expect to update them any time soon due to the pressure from other commitments. This is mostly for historical purposes (and the faint hope that one day, I will have the chance to get back to them). If you have a strong interest in taking over one of these projects, though, you should contact me.
The list includes some particulars about the last state of the project, and the reason I'm not pursuing it now. Hopefully it won't be too depressing or destructive to my reputation. :-)
Status: On Hiatus - Might Be Back
One problem faced by collaborative free culture multimedia projects is that of managing attribution and licensing information (the credits list) for all the different creative elements. I felt it would be much better if this information was embedded in the data files -- something which most file formats allow for, but which is not widely supported by software in any kind of consistent way.
To improve this situation, I started work on a python-based command line tool with a plugin architecture for applying metadata to files and extracting them. I called it "Palimpsest", mainly for metaphorical reasons, though I did come up with a backronym: "Python Attribution & Licensing Information Metadata Processor with Systematic Extensions for Sundry Types". Which was silly of me, but why not?
Currently Palimpsest has some basic functionality implement, but it has only one fully-functional backend which works with GIF files. I have a partial PNG implementation, but I'm not too happy with it. It will be relatively easy to write Ogg format support using the available Python libraries, and JPG support is pretty simple, although the EXIF extensions are a little annoying.
I also created a Glade design for a GUI application front-end for Palimpsest, though there is nothing to connect this design to the existing code, as yet.
The main stalling point, though, was the implementation of the XML/RDF code and the XMP support, because I'm just not familiar enough with them. I do have some leads I want to try out on simplifying that part of the code when I get the chance. I also do not have any experience using Glade to control a Python program, but then, that's part of the reason for doing it.
When time allows, I plan to:
- Restore the website from backup
- Use Sparta to solve the XMP support problem
- Implement the already-designed Glade GUI with PyGTK
- Possibly also create a Qt version (?)
The need for this program has softened a bit. Although consistency is still a problem, there are more tools that honor embedded metadata these days. Also, wiki software makes handling metadata "out of band" easier. Still, it would be useful on a number of projects, including "Lunatics". The main question is just whether I have any time for programming work.
There are now some other projects out there with similar goals, so I might simply let this one go (permanently), since I really don't have time for it.
Status: On Hiatus - Low Priority
Inkscape extension to procedurally create "toning" effects -- like "screentones" used in graphic arts (they are especially popular in Japanese Shojo manga). They could also be used to create cloth patterns for use with Spoonflower.
I created a Glade GUI for this, but again, this is something I'm just learning how to do. There is another problem, which is how to integrate it with Inkscape's extension system (which doesn't make it easy to your own persistent GUI).
Status: On Hiatus - Low Priority
A learning project, grown from DigiTone. Cassie is the Clip Art and Skinning System Inkscape Extension, which would provide a clipart library and tools for automatically generating and compositing images as part of a build system. So it's also the successor to the Buildimage idea.
Not much done yet -- still haven't figured out how to get around the roadblocks with Inkscape. Probably need some kind of interprocess approach where Cassie runs as a separate process and exchanges information through extensions in Inkscape. Or maybe I need to patch Inkscape. I'm not sure.
Status: Dead - Bitrot
This was a working extension for Zope 2.5. However, with a later Zope (2.7, I think) it simply stopped working. I never had a chance to figure out why, although it seems to be related to a change in the acquisition code.
It was really meant to support Narya, and wasn't important enough for me to keep up to date after I abandoned that project.
Status: Dead - Superceded by CASSIE
Programmers use GNU make utilities to automate the build process for programs. It works great for this. But it's a poor fit for building image resources used for skinning applications. I wanted something that would make this much easier. BuildImage was my first concept -- very close to the command line make utility.
However, BuildImage was not totally satisfying. Specifying how to create images from original art was far too manual and difficult. Instead, I felt you should be able to draw what you want in a program like Inkscape. From this came the idea that I should really be developing an Inkscape extension of some kind. Also, I'm not aware that BuildImage itself caught the imagination of anyone but me. So I decided to let it go, and look towards making a better system in the future sometime.
- The Python Universe Builder
Status: PUB 1 is Stagnant, PUB 2 is Dead
The original P.U.B. was created by Joseph Strout in the 1990s. However, he had no more time or interest in maintaining it (his next project was a "MOO" based on a similar design concept), and it had been ignored for several years.
I took over PUB with the intent of updating it to a more modern Python, making it easier to internationalize, and adding a graphical adventure game shell ("Universe") on top of it. This would be the game engine for The Light Princess. But it would also continue to be usable as an IF engine, and I hoped to add some ideas I had read about "broad, shallow agents" as non-player characters.
By the time I did this, though, Light Princess was already starting to wind down. At one point, a student named Gabriel Jagenstedt became interested in working with PUB, and he had his own vision for how it might work.
Unfortunately, we never got these visions to mesh, the dependencies became a mess, and so the "PUB 2" rewrite collapsed. We have a heap of code, but it doesn't do much.
The original "PUB 1" is available from the website, though, updated to work with more recent versions of Python (I believe it works up to at least Python 2.5), and it is possible to write IF games with it.
- The Light Princess Graphic Adventure Game
Status: Definitely Mostly Dead... Probably
I started this project with my wife and partner, Rosalyn Hunter, in 2000, in response to claims that the aesthetic quality of free software games was poor because artists would not be willing to contribute under free-licensing terms. I suspected that this was more of a problem of networking and recruiting (i.e. that the programmers didn't know any artists), and so I approached it primarily from that point of view. Ironically, it was primarily the programming side that let us down on this project (I was good at it then, and didn't manage to recruit anyone who was skilled and willing enough to do it).
The project continued until about 2001, when it became clear that the programming problems weren't going to be solved fast enough, and when I got a full-time job at Caltech. So I tabled the project then. My wife and I did a couple of quiet revivals of the project in 2005 and 2007, doing some of the additional post-processing of artwork, and creating an introductory animatic.
As it sits, "The Light Princess" has a story concept, a basic game-play idea (but with no details), a node-and-link design for the "Day 1" part of the game, and a fair amount of concept art, including character designs by Katherine Chi, Daniel Fu, Corene Werhane, and Marc Yang. There is an introductory animatic which also mocks-up some of the concepts for game play.
The Light Princess also served to identify many of the missing infrastructural elements needed to promote more creative projects of this type, and some of my later projects were meant to address parts of these needs. Others have been solved in the meantime by completely unrelated projects, but I have kept a close watch on these developments, partly as a result of my experience with this project.
In brief: we didn't make a game, but we had fun, and we learned a lot.
- Narya Project Incubator
Status: Totally Dead As-Is, Might Resurrect the Bargaining System
The original concept for the narya.net domain was to set up a incubator similar to Sourceforge (though obviously much smaller!) for what would now be called "Open Hardware" projects.
It was conceived as an integrated concept with many features that existed in other software, but which I wanted to bind more tightly together:
- Documents (Somewhat like wiki)
- Version control
- Support for Computer-Aided Design documents
But what was really the unique feature was the "Bargaining" system, originally called "Bazaar" (but I later adopted "Narya Bazaar" or "Narya Bargaining" to avoid confusion with the distributed version control system called "Bazaar" which came out in the meantime).
The idea was to combine an RSPP-inspired collective patronage system with flexible donation pledges with a reverse-auction system in which suppliers could bid to provide needed services. There were really three major parties in each transaction:
- The project developers - who created the specification
- The donors - who contributed money
- The vendors - who provided goods and services
In addition, a fourth party would act as a trusted mediator to verify that a vendor product met the given specification, and therefore release the funds collected by donors. The idea was to solve the common problem with open hardware of raising funds for prototype manufacturing, engineering services, and other problems that faced non-profit, free-culture open hardware projects.
All that I really managed to produce was a very buggy Zope-based forum.
In retrospect, it's clear to me now that I would've been much better off to develop the critical element only (i.e. the Bargaining system), and design it as a plug-in for some existing CMS (perhaps Plone or Drupal), or as a "cloud" service to be integrated generically in any site. I may yet try to do that myself, or collaborate with someone else wanting this kind of feature.