Raising the bar: Now there is no lawn

Recently I found an issue in augeas that I fixed, so I wanted to be a good netizen and report the problem along with the patch.

I've never needed to contribute to a Fedora Hosted project before, so I do not possess a Fedora Account, which is required for their bug reporting system.

OK, no big deal, their account signup is not too onerous: email, name, password, security Q&A and a math capcha....  A dozen tries later, I finally abandon the idea that I would ever get past the image capcha.  The validator must be using the new math, because last time I checked 22+53=75.

They have an audio capcha option, too, let's try that....  I'm guessing it's using the Ogg Vorbis codec, because I couldn't get it to play.

Alright, let's try asking on the IRC channel if the account system is having problems....  Except it's been so long since I've used freenode that I have no idea what my password might have been, so I can't join any channel to ask.

Mailing list! There's a developer mailing list!  I'll just drop them a quick note with the patch.

You are not allowed to post to this mailing list, and your message has been automatically rejected.  If you think that your messages are being rejected in error, contact the mailing list owner.

I really don't feel like joining the list just to post a single patch, because the chances that I'll ever find a bug worth reporting again are pretty slim.

By this point, I've already spent more time just trying to report the bug and the fix than it took to find and fix the bug in the first place.

UNCLE!

Finally I looked through the mailing list and just dropped a message with the patch to one of the maintainers, and he committed the fix -- thanks David!

Once upon a time, the Internet used to be an open and collaborative environment, but these days, it's just wall after wall to keep the pests off the lawn.

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.