But is that really the first step? I'm finding that what I build is dependent on who I'm building for. Having launched an alpha version of the product and shaken out many of the bugs in the base functionality, I'm going to have to make some tough decisions about what I concentrate my time on next. These all revolve around who I'm developing the product for:
My Family: Remember that I developed the transcription software to help accomplish a specific goal: transcribe Julia Brumfield's diaries to share with family members. The features I should concentrate on for this audience are:
- Finish porting my father's 1992 transcription of the 1918 diary to FromThePage
- Fix zoom.
- Improve the collaborative tools for discussing the works and figuring out which pages need review.
- Build out the printing feature, so that the diaries can be shared with people who have limited computer access.
Institutional Users: This blog has drawn interest from a couple of people looking for software for their institutions to use. For the past month, I've corresponded extensively with John Rumm, editor of the Digital Buffalo Bill Project, based at McCracken Research Library, at the Buffalo Bill Historical Center. Though our conversations are continuing, it seems like the main features his project would need are:
- Full support for manuscript transcription tags used to describe normalization, different hands, corrections/revisions to the text, illegible text and other descriptors used in low-level transcription work. (More on this in a separate post)
- Integration with other systems the project may be using, like Omeka, Pachyderm, MediaWiki, and such.
The problem is that there's very little overlap between the features these groups need. I will likely concentrate on family and volunteers, while doing the basics for THATCamp. I realize that's not a very tight focus, but it's much clearer to me now than it was last week.
How much work would it take to get it into a state where other people can extend it according to their needs?
Most of the work would be organizational.
1. Choose the appropriate license that serves my needs (probably some sort of non-commercial use Open Source -- need to pay a lawyer on this)
2. Figure out how to run an open source project -- this is something I've never even contributed to before, and I'm sure plenty of pitfalls exist I haven't thought about.
3. Carve out the time to orchestrate updates to the core system and (more importantly) provide support to developers.
1. Extract dead code that introduces unnecessary dependencies. My decision last Fall to use the restful_comments plugin broght with it a host of dependent packages, none of which are in use.
2. Create a "phone home" system -- based on Matt Mullenweg's much-repeated advice, it's important to be able to navigate the ecosystem of FromThePage instances.
3. Do whatever infrastructural things are necessesary -- like move to RubyForge or Git or somesuch.
4. Do whatever technical things are needed to support a system of plugins: in a scenario where multiple instances of FromThePage are running with different customizations, I imagine that some of these (e.g. TEI-WYSIWYG) would be shared between different instances. This would require both plugin architecture in the FromThePage software, and a plugin directory akin to #2.
I do think that a distributed, open-source system is almost certainly the way to satisfy these competing user groups. Unless somebody funds me, having myself as the sole, part-time developer doesn't scale at all.
If you're interested in a more informal, more immediate arrangement, send me a note with your thoughts.
Post a Comment