deborah: the Library of Congress cataloging numbers for children's literature, technology, and library science (Default)
I've been involved with a lot of non-profits over the years, and as I watch the current round of drama around the OTW elections and code rollout, I can only think how normal, even minor, this drama seems as non-profit drama goes. I know that's cold comfort to the people who are miserable, piled upon, abused, or what-have-you, but it comforts me, because I know there's nothing unusually wrong.

Some observations from the peanut gallery )

I do wish I had participated in one of the candidate chats, because I would have asked whether all roles are expected to be volunteer indefinitely. I don't know of any organizations who have managed to do systems administration in a completely volunteer way. Naomi, I think, understands the difficulties of why systems is so difficult to do as volunteer, and I'd like to know what she and the other candidates think about possible solutions to that problem.

In any case, everyone I've worked with at the OTW has been great: the angry people and the placid people, the burnt out people and driven people, the people who focus on the Archive as the flagship of the organization and the people who think the Archive already draws too many resources away from other projects. Like many nonprofits, the organization's biggest source of friction is that there are too many bright people who care passionately. I'm not going to downplay how very real a problem that is for sustainability. But on the other hand... Well. I think I've absorbed too much business-ese lately, because I'm thinking that if I were going to do a Strengths, Weaknesses, Opportunities, and Threats analysis of the OTW, the "too many bright people who care passionately" would be both Opportunity and Threat.




As a side note: The AO3, from the inside, does a better job of automated tests (in that it has them) and QA than most other software projects I know, and yes, Dreamwidth is nowhere near as good at the OTW at these, I saw you people over there claiming that DW does it better. I've seen inside both sausage factories. Software development is hard, yo, Anyone who thinks crappy releases never see the public has never used Windows Vista.
deborah: the Library of Congress cataloging numbers for children's literature, technology, and library science (Default)
I've been enjoying Public Knowledge's 4-part video series "We Are Creators, Too," but I never expected Francesca Coppa discussing vidding to come across my blog roll!

Kudos to PK for treating vidding like any other form of video remix, not as some weird dysfunctional female behaviour. And kudos to PK for doing the shockingly unusual behaviour of not normativizing male video creation; 3 of the 4 interviews are with women, and video remix not treated as a male activity that some women do as well.

And of course, kudos to Francesca for for an excellent interview which touches on so many of the key points of vidding culture, history, and law.
deborah: the Library of Congress cataloging numbers for children's literature, technology, and library science (Default)
[Tagged as, among other things, otw, because even though I am dealing with these issues as a professional I think that The Organization for Transformative Works is very well-placed to be one of the few organizations prepared to confront operational preservation from the outset. After all, the OTW has to deal with one even more frightening aspect of operational preservation: it is an entirely volunteer-run organization which promises perpetual preservation. It takes a lot of planning and commitment to be prepared to follow through on a commitment like that. Luckily, the OTW has both.]

Introductory thoughts on Operational Preservation )

I would love to get comments from the community on this, because I truly believe that this could be a very useful model for organizations designing digitization projects. I know I'm going to prompt my institution to follow this matrix for all new digitization efforts.

Problem Statement: When an archivist deposits material in a digital archive, he or she often has assumptions that object is preserved in perpetuity, just as it would be worried a physical object. Depositors of digital material often have the same assumptions, as do institutional administrators. However, the assumptions of the software development and maintenance community do not assume permanence on the same scale in which archivists are accustomed to providing permanence. Moreover, administrators (and archivists) often have unrealistic assumptions about the labor and costs involved in daily operational maintenance to provide digital preservation, which are -- if not higher -- certainly different from the operational maintenance costs for providing physical preservation. Even worse, many digital preservation projects are funded by limited-duration soft money instead of out of an operational budget.

Or, in a nutshell, we need to remember that Digital preservation has an ongoing operational cost which cannot be provided within the archive.

Operational Preservation: To that end, I am proposing this matrix for new preservation and archival projects to see if they have thought of the requirements necessary for permanent preservation.

Anything calling itself a digital preservation project has to be prepared, in perpetuity, to provide all items down the left-hand column for all of the items in the top row. Funding is really a redundant item -- by "Labor", I mean funding for staff to provide all of the work involved, and "Physical facility" is really something which can be provided by funding -- but the fact that digital preservation requires ongoing operational money is too important to ignore. By "Bureaucratic support" I mean policies and procedures in place which support the operational business of preservation at an organizational level.

Operational Preservation Matrix
Labor Physical facility Bureaucratic support Funding
Existence of the datastream
in a file system or database
. . . .
Object access via handle/doi/uri . . . .
Maintenance, repair, and upgrade
of hardware (server, disk, etc.)
. . . .
Maintenance, patching, and upgrade
operating system
. . . .
(The following tasks are not as
essential, but still very important)
. . . .
Rolling forward file formats . . . .
Transferring data to more modern
repository and software tools when appropriate
. . . .
Modernizing user interface as appropriate . . . .


(Of course, traditional preservation of physical objects is also an ongoing operational cost. Physical objects require extensive physical facilities with narrow environmental limitations, they require re-housing and repair, they require maintenance and supervision. But these ongoing operational tasks can be performed by archivists with traditional skills. The technological operational tasks of a digital archive often can't be performed even by technologically-trained archivists, because the institution will have specific requirements about who is able to, say, maintain the network.)
deborah: the Library of Congress cataloging numbers for children's literature, technology, and library science (Default)
I've been getting increasingly concerned about what I see as a too-shallow view of sustainability in digital preservation. There's been a lot of lip service paid over the last few years to preservation, and I have certainly heard talks by grant-funding agencies in which they explained that they are now only funding grants which have sustainability written into the grant structure. Yet time and time again, I see soft money being awarded to projects for which the project administrators clearly have only the vaguest idea of what sustainability really means in a software environment.

I don't see this as anyone's fault, mind you. Software developers and IT folks aren't used to thinking of software projects in terms of Permanence. In the traditional software world, the only way something is going to be around forever is if it's going to be used all that time -- for example, a financial application which is in constant use needs to be constantly up. But archival digital preservation has a very different sense of permanence. For us, permanence might mean that you build a digital archival collection once, don't touch its content again for 10 years, but can still discover all of its preserved content at the end of those 10 years.

Meanwhile, in Internet time, a project which has been around for two years is clearly well past its prime and ready to be retired.

Repository managers are putting all of this great work into the repository layer* of preservation: handles and DOIs, PRESERV and PRONOM, JHOVE and audit trails and the RLG checklist. But meanwhile, all of these collections of digital objects -- many of them funded by limited-duration soft money -- are running on operating systems which will need to be upgraded and patched as time passes, on hardware which will need to be upgraded and repaired as time passes, on networks which require maintenance. Software requires sustenance and maintenance, and no project which doesn't take into account that such maintenance requires skilled technical people in perpetuity can succeed as perpetual preservation. Real sustainability means commitment from and communication with the programmers and sysadmins. It requires the techies understand an archivist's notion of "permanence", and the librarians and archivists (and grant agencies) understand how that a computer needs more than electricity to keep running -- it needs regular care and feeding.

(This, by the way, is one of the reasons I'm so excited by the OTW Archive of One's Own and the Transformative Works and Cultures journal. The individuals responsible for the archive and the journal *do* have a real understanding of and commitment to permanence down to the hardware and network provider level. Admittedly, it's a volunteer-run, donation supported organization, so its sustainability is an open question. But it's a question the OTW Board is wholeheartedly investigating, because they understand its importance.)

*I'm somewhat tempted to make an archival model of preservation that follows the layered structue of the OSI model of network communication. Collection policy layer, Accession layer, Content layer, Descriptive Metadata layer, Preservation Metadata layer, Application Layer, Operating System layer, Hardware layer. Then you could make sure any new preservation project has all of those checkboxes ticked. Sort of an uber-simplification of the RLG Checklist, in a nice, nerd-friendly format.
Page generated May. 23rd, 2017 10:21 pm
Powered by Dreamwidth Studios