One of the pleasures of maintaining the crowdsourced transcription tool list is learning about systems I'd never heard about before. One of these is Unbindery, a tool being built by Ben Crowder for audio and manuscript transcription as well as OCR correction. Ben was gracious enough to grant me an interview, even though he's concentrating on the final stretch of development work on Unbindery.
Thanks! Probably private projects -- I've been looking forward to using Unbindery to transcribe my journals, but haven't wanted them to be open for just anyone to work on. I'm also very excited about chunking audio into small segments (I used to publish an online magazine where we primarily published interviews, and transcribing two hours of audio can be really daunting).
Tell us more about how Unbindery handles both audio transcription and
manuscript transcription. Usually those tools are very different,
How did you come up with the idea for Unbindery?
I had done some Project Gutenberg work back in 2002, and somewhere along the way I came across Distributed Proofreaders, which basically does the same thing. A few years later, I'd recently gotten home from an LDS mission to Thailand and wanted to start a Thai branch of Project Gutenberg with one of my mission friends. He came up with the name Unbindery and I made some mockups, but nothing happened until 2010 when I launched my Mormon Texts Project. Manually sending batches of images and text for volunteers to proof was laborious at best, so I was motivated to finally write Unbindery. I threw together a prototype in a couple weeks and we've been using it for MTP ever since. I'm also nearing the end of a complete rewrite to make Unbindery more extensible and useful to other people. And because the original code was ugly and nasty and seriously embarrassing.
In my experience, the transcription tools that currently exist are
very much informed by the texts they were built to work with, with
some concentrating on OCR-correction, others on semantic indexing, and
others on mark-up of handwritten changes to the text. How do you feel
like the Mormon Texts Project has shaped the features and focus of
Mormon Texts Project has been entirely focused on correcting OCR for publication in nice, clean ebook editions, which is why we've gone with a plain old text box and not much more than that. (Especially considering that we were originally posting the books to Project Gutenberg, where our target output format was very plain text.)
What is your grand dream for Unbindery? (Feel free to be sweeping
here and assume grateful, enthusiastic users and legions of cobbler's
elves to help with the code.)
To get men on Mars. No, really, I don't think my dreams for Unbindery are all that grand -- I'd be more than satisfied if it helps make transcription easier for users, whether working alone or in groups, and whether they're publishing ebooks or magazines or transcribing oral histories or journals or what have you.
In an ideal world it would be wonderful if a small, dedicated group of coders were to adopt it and take care of it going forward. But I don't expect that. I'll get it to a state where I can publicly release it and people can use it, but other than bugfixes, I don't see myself doing much active development on Unbindery beyond that point. I know, I know, abandoning my project before it's even out the door makes me a horrible open source developer. But to be honest with you, I don't really even want to be an open source developer -- I'm far more interested in my other projects (like MTP) and I want to get back to doing those things. Unbindery is just a tool I needed, an itch I scratched because there wasn't anything out there that met my needs. People have expressed interest in using it so I'm putting it up on GitHub for free, but I don't see myself doing much with Unbindery after that. Sorry! This is the sad part of the interview.
What programming languages or technical frameworks do you work in?
It seems like you're putting a lot of effort into ease of deployment.
How do you see Unbindery being used? Do you expect to offer hosting,
do you hope people install their own instances, or is there another
model you hope to follow?
I won't be offering hosting, so yes, I'm expecting people to install their own instances, and that's why I want it to be easy to install. (There may be some people who decide to offer hosting for it as well, and that's fine by me.)
How can people get involved with the project?
Coders: The code isn't quite ready for other people to hack on it yet, but it's getting a lot closer to that point. For now, coders can look at my roadmap page to see what tasks need doing. (Also, it won't be long before I start adding issues to GitHub so people can help squash bugs.)
Other people: Once the core functionality is in place, just having people install it and test it would probably be the most helpful.