EZproxy wish list: Collaborative stanza maintenance

EZproxy is configured via little chunks of configuration snippets commonly called "stanzas".  OCLC maintains a large list of these stanzas, the EZproxy Wiki has a few more stanzas, and better vendors will generally not look at you like you're from Mars if you ask for an EZproxy stanza for their service.

Sometimes the stanzas even match.

There are regularly requests on the EZproxy mailing list for updated stanzas for vendors, comments on how a vendor stopped using a particular version of a stanza X years ago, etc.

I've been working with one vendor for a while now to get a fix into their stanza so that I can tell OCLC to update the ones on their web site.  When another vendor added a new service, and in order to interact with that new service a specific way, I had to tweak their stanza to allow linking to it directly.  I don't think anyone else in the world has this tweak in their stanza.

There needs to be a better way.

While thinking about this, it occurs to me that one of the key things that is missing is a feedback cycle.  There is plenty of collaboration on the EZproxy mailing list, but I am yet to see a vendor pay attention to that list. OCLC's hands are tied, because they don't know the services like the vendor is supposed to.

In the spirit of The Cathedral and the Bazaar, I offer this idea for a way forward.

First let's define the problem:

• OCLC publishes the stanzas on their web site, but they defer to the vendors for the content.  
• Vendors (mostly) give out stanzas, but changing one seems to be a Herculean effort.  
• Wiki pages are collaborative, but may not be the best tool for the job.
• All of this requires human interaction to copy the stanza into config.txt and having the proxy maintainer keep it current.
• There is no notification mechanism to keep proxy maintainers notified when stanza changes are made.  OCLC puts the date the stanza was last updated on their web site, but you still have to be actively looking to see it.

Now let's make some requirements:

• There needs to be a collaborative environment
• There needs to be an authoritative source
• There needs to be a better way to find out when stanzas are updated
• There should be a way to create and use your own versions of the stanzas
• There should be a way to automatically update stanzas

If you take a step back, these requirements are a lot like what a software developer would want, too.  Except stanzas would be source code.  And "create and use your own versions" would be called forking or branching.

So here's the radical idea:

Create a source code repository (like GitHub) to hold the EZproxy stanza files.  This satisfies the collaboration requirement.  

Have the owner of this master repository be OCLC.  There's your authoritative source.

Use the SCM features (activity streams, RSS feeds, commit mails, etc) to satisfy the update notification requirement.

Now, here's where it gets interesting...

Extend the EZproxy admin interface to be able to point to a GIT repository, and have EZproxy pull a copy of the repository locally.  This could be any GIT repository, either the official OCLC repository, or one that you forked with your own stanza versions.  It could be hosted at GitHub, or running locally.

Once the repository is downloaded, present the EZproxy admin with the services maintained within that repository to enable/disable.  This means that there is no reason not to have a canonical source with stanzas for everything, since you do not have to use them all, only the ones you want.

And finally, have EZproxy run a periodic update from the repository either manually or automatically.  If you're using the OCLC authoritative repository, you could receive updates as they are released, or just update between terms.  If you have forked the OCLC repository, you can pull updates from the master repository into yours to stay current.

Now you have all the moving parts for collaborative stanza maintenance:

• OCLC establishes a master repository and imports the existing stanzas
• Vendors for the repository and maintain their own stanzas, allowing OCLC to pull their changes back to the master
• EZproxy administrators subscribe to the repository of their choice (defaulting to OCLC, of course)
• EZproxy administrators can choose fork either OCLC or Vendor repositories for their own use, and suggest changes back
• EZproxy administrators can subscribe to other administrator's repositories
• Changes can be pulled between repositories, maintaining version history

So there you have it.  A way to embrace chaos while bringing a modicum of order.  A way to publish the stanzas so that they can be maintained, updated, published, and imported in a sane way.  A way to enable EZproxy administrators to work together in an environment that is more geared toward collaboration than the existing channels.