Author Archives: Tom Scheinfeldt

Briefly Noted for November 9, 2010

@kfitz and @amandafrench at Bryn Mawr — Friend of CHNM, Kathleen Fitzpatrick and our very own Amanda French will be at Bryn Mawr this Thursday, November 11, 2010 to anchor the National Undergrad Symposium on Digital Humanities. The symposium aims to explore the ways in which “digital publishing can create new openings for undergraduates to enter significant academic conversations.”

Masters Degree in Digital Humanities at UCL — University College, London is offering a new MA/MSc in Digital Humanities. As there are very few degree programs in digital humanities, this is an experiment to watch. According the organizers, the program “will allow students who have a background in the humanities to acquire necessary skills in digital technologies, and will also make it possible for those with a technical background to become informed about scholarly methods in the humanities.” Students will also take advantage of UCL’s location through work placements with libraries, archives, cultural heritage institutions, and digital culture organizations based in central London.

Tenleytown Heritage Trail — I was very happy to return home this week to find nearly twenty new illustrated narrative historical markers in my neighborhood. The Tenleytown Heritage Trail provides a self-guided tour of the “top of the town,” Washington DC’s highest neighborhood. Beginning at the corner of Wisconsin Avenue and Albemarle Street near the Tenleytown-AU Metro stop, the trail chronicles Tenleytown’s history from its origins as a colonial anchored by John Tennally’s taven, through its key strategic value in the Civil War, to its rich and diverse 20th century history. I hope to get some time to walk the trail before the cold really sets in.

Briefly Noted for November 4, 2010

Jason Scott at MITH — I am extremely bummed I won’t be in town for this. Next week our friends at the Maryland Institute for Technology and the Humanities (MITH) are hosting a two day visit by Jason Scott, computer historian and documentary filmmaker. On Monday November 8th, Scott will introduce a screening of his latest film, and on Tuesday November 9th, Scott will deliver a talk as part of MITH’s Digital Dialogues series. Please see the full announcement for more details. The events are open to the public (that means you).

Geoffrey Rockwell on Method and Theory — In this post about a recent spate of “cluster hires” in digital humanities at places like the University of Iowa and Georgia State University, Geoff Rockwell notes: “The digital humanities, in part because of the need for practicioners with extensive skills, tend to look undertheorized, and it is. It is undertheorized the way any craft field that developed to share knowledge that can’t be adequately captured in discourse is. It is undertheorized the way carpentry or computer science are. To new researchers who have struggled to master the baroque discourses associated with the postmodern theoretical turn there appears to be something naive and secretive about the digital humanities when is mindlessly ignores the rich emerging field of new media theory. It shouldn’t be so. We should be able to be clear about the importance of project management and thing knowledge – the tacit knowledge of fabrication and its cultures – even if the very nature of that poesis (knowledge of making) itself cannot easily (and shouldn’t have to) be put into words. We should be able to welcome theoretical perspectives without fear of being swallowed in postmodernisms that are exclusive as our craft knowledge. We should be able to explain that there is real knowledge in the making and that that knowledge can be acquired by anyone genuinely interested. Such explanations might go some way to helping people develop a portfolio of projects that prepare them for the jobs they feel excluded from. Put another way, there is nothing wrong is valuing thing knowledge as long as we also recognize the value of theoretical critique.”

@alexismadrigal unpacks the Google Books search algorithm — Writing for the Atlantic Monthly, Alexis Madrigal provides insights into how Google indexes book data and uses (or misuses) library metadata.

The long haul: Why do academics take so long to hire?

I got in a little bit of a friendly dust up yesterday on Twitter when I asked, “As I watch colleagues embark on the 2011 #jobmarket I have to wonder, why on earth does it take humanities departments 6+ months to hire?”

Needless to say, I received a lot of answers. I won’t list all of them but I think the following distillation does them justice:

  1. Because the pool of applicants is large;
  2. Because the hiring process follows the academic calendar;
  3. Because faculty members are busy people and search committee activities must be scheduled around other commitments;
  4. Because we take time to read candidates’ scholarship as well as their resumes;
  5. Because tenure track decisions have long term consequences;
  6. Because hiring depends on building consensus across a department.

All of these reasons make sense to me. I’m just not sure they answer my question. They seem more like answers to the question of “how” it takes so long to hire rather than “why” it takes so long to hire.

(At this point, I should disclose that I have never formally participated in a tenure-track search process either as a candidate or a search committee member, so some of what follows may be totally naive and off base. If so, I apologize. But I have watched the process for years from a short distance as a friend of both candidates and committee members. I’m also a research faculty member and manager who does a fair bit of hiring himself, so if nothing else, I may have a valuable near outsider’s perspective to contribute. I hope so.)

Why, for example, does the hiring process have to follow the academic calendar? Couldn’t we shorten it to six weeks in December and January or schedule it around spring break or do it in the summer (paid, of course)? The answer comes back that we can’t shorten the process because the pool of applicants is so large. But there is a circularity to this line of thinking. If departments didn’t all hire on the same schedule, if there were multiple (necessarily shorter) hiring seasons, then some people would already know in September that they had a job and wouldn’t enter the November round at all. Still others could skip both the summer and winter seasons and wait until spring. Interview scheduling and campus visits would be made much easier as well. It seems obvious that if there wasn’t just *one* hiring season, there wouldn’t be so many candidates in any given season. This in turn would put paid—to some extent at least—to reasons and three and four. If the season was shorter and there weren’t so many candidates, it wouldn’t take up so much committee member time and energy either in meetings or in reading.

There are other questions one might ask; each of these reasons has problems when you dig a little deeper. For example, there are lots of busy people in lots of important jobs who juggle serving on hiring committees with normal work commitments. All small and medium sized businesses do their own hiring, and even at big companies with professional human resources departments, executives are heavily involved in making important hiring decisions. How do they manage the process so it doesn’t overwhelm their other work? Likewise, lots of hiring decisions in lots of fields have major, long term consequences—civil engineering comes to mind—but I’m guessing those fields usually manage to hire people in less than six months. At the very least they don’t stack the deck against a quick hire in advance, setting things up so that it can never take less than five or six months. What are they doing to insure they’re making safe, yet speedier hiring decisions?

Mainly, if we are going to accept any of these practices—including reading everyone’s scholarship and building consensus across departments—as valid answers to the “why” question rather than the “how” question, we first need to know whether they actually lead to better hiring decisions. I’m not sure we know with any certainty that they do. How many applicants’ scholarship do we really have to read to narrow it down to two or three? Is trying to get the bulk of the department membership on board an exercise in futility that causes more bad blood than it avoids?

Finding answers to these questions may lead us right back to where we started, but they’re worth asking on the chance that they could help us do a better job of placing the right people in the right jobs at lower cost and with fewer headaches. When every year I hear the same complaints from all sides about the academic hiring process, “the way we’ve always done it” just doesn’t satisfy as an answer.

Briefly Noted for November 3, 2010

@sramsay goes on record — Steve Ramsay argues against anonymity online, asking faculty “to consider whether it’s appropriate for someone who is paid to be a teacher and an intellectual to behave like an Anonymous Coward on Slashdot” and reminding us that we “are not political dissident[s] fearing reprisals from a hostile government.” Something good to keep in mind whenever we start to take ourselves too seriously.

What’s a bigger deal than a $300 smartphone? A free smartphone — T-Mobile is offering the LG Optimus T, a more or less full featured Android device for free with a two year contract. This could really change things, not only for Android, but for those of us building mobile websites and apps for teaching, research, and cultural heritage. For just the price of a monthly contract ($79 for 500 talk minutes and unlimited SMS and Internet), we’ll soon see smartphones in most of our students’, colleagues’, and visitors’ pockets.

Tomboy Notes — It’s the little things that make good software. One of the best little things about Linux/Gnome/Ubuntu is Tomboy, a simple little note-taking package that just plain works. I’m only running Linux about half-time these days—alas, I’ve been forced back to dual-booting Windows for MS Office, easy projector support, etc.—but I’m still running Tomboy full time and syncing across platforms with help of the gtk-sharp and Ubuntu One. There’s a Mac version too. If you’re searching for a good note taking tool, I highly recommend dipping your toe into the Linux bathtub and giving Tomboy a try.

Failing Quickly at Google — James Fallows’s much discussed Atlantic Monthly article on Google and the future of journalism contains this little gem from Josh Cohen of Google News: “We believe that teams must be nimble and able to fail quickly.” Something for managers of teams working in digital humanities and cultural heritage to remember.

Digital rocking the public history job market

Things are looking up for digitally minded public historians. At least six new media focused tenure-track academic public history positions are open this fall, including:

Happy hunting!

Alt-Conference Venues

A discussion today on Twitter about the rising costs of conference space, even on campuses, which in many cases charge their own faculty and staff for use of facilities, got me thinking that we humanists should be thinking more creatively about where to hold our gatherings.

The Hilton is nice. But as THATCamp has shown, it’s not an essential (or maybe even desirable) ingredient for hosting a good conference or enabling productive scholarly communication. Just as urban artists find cheap, usable—even cool—studio space in warehouses and garages, we should find ourselves some alternatives to the traditional hotel ballrooms and campus auditoriums.

So, here’s the start of a list. On the one hand, there are some places in most cities that rent space at low cost. In this category, I’d put the YMCA, local churches and synagogues, local public schools, those big suburban wedding halls they advertise on late night cable, and KOA and other campgrounds (hat tip, Brian Croxall). On the other hand, there may be places that are willing donate space that is otherwise unused on weekends. What about asking a local business for use of its offices and providing them with documentation for tax purposes of the in-kind charitable donation? What about asking a local foundation for use of its offices in lieu of a monetary donation?

None of these places will make us feel as important as we do when checking in at the New York Hilton. But they’d all serve just as well for communicating ideas. Please add your ideas for alt-conference venues in comments. Let’s build a list.

Omeka and Its Peers

As an open source, not-for-profit, warm-and-fuzzy, community service oriented project, we don’t normally like to talk about market rivals or competitive products when we talk about Omeka. Nevertheless, we are often asked to compare Omeka with other products. “Who’s Omeka’s competition?” is a fairly frequent question. Like many FAQs, there is an easy answer and a more complicated one.

The easy answer is there is no competition. 😉 Omeka’s mix of ease of use, focus on presentation and narrative exhibition, adherence to standards, accommodation for library, museum, and academic users, open source license, open code flexibility, and low ($0) price tag really make it one of a kind. If you are a librarian, archivist, museum professional, or scholar who wants a free, open, relatively simple platform for building a compelling online exhibition, there really isn’t any alternative.

digital_amherst

[Figure 1. Digital Amherst, an award-winning Omeka powered project of the Jones Library in Amherst, MA.]

The more complicated answer is that there are lots of products on the market that do one or some of the things Omeka does. The emergence of the web has brought scholars and librarians, archivists, and museum professionals into increasingly closer contact and conversation as humanists are required to think differently and more deeply about the nature of information and librarians are required to play an ever more public role online. Yet these groups’ respective tool sets have remained largely separate. Library and archives professionals operate in a world of institutional repositories (Fedora, DSpace), integrated library systems (Evergreen, Ex Libris), and digital collections systems (CONTENTdm, Greenstone). Museum professionals operate in a world of collections management systems (TMS, KE Emu, PastPerfect) and online exhibition packages (Pachyderm, eMuseum). The humanist or interpretive professional’s online tool set is usually based around an off-the-rack web content management system such as WordPress (for blogs), MediaWiki (for wikis), or Drupal (for community sites). Alas, even today too much of this front facing work is still being done in Microsoft Publisher.

The collections professional’s tools are excellent for preserving digital collections, maintaining standardized metadata, and providing discovery services. They are less effective when it comes to exhibiting collections or providing the rich visual and interpretive context today’s web users expect. They are also often difficult to deploy and expensive to maintain. The blogs, wikis, and off-the-rack content management systems of the humanist (and, indeed, of the public programs staff within collecting institutions, especially museums) are the opposite: bad at handling collections and standardized metadata, good at building engaging experiences, and relatively simple and inexpensive to deploy and maintain.

Omeka aims to fill this gap by providing a collections-focused web publishing platform that offers both rigorous adherence to standards and interoperability with the collections professional’s toolkit and the design flexibility, interpretive opportunities, and ease of use of popular web authoring tools.

omeka_tech_ecosystem

[Figure 2. Omeka Technology Ecosystem]

By combining these functions, Omeka helps advance collaboration of many sorts: between collections professionals and interpretive professionals, between collecting institutions and scholars, between a “back of the house” and “front of the house” staff, and so on.

omeka_user_ecosystem

[Figure 3. Omeka User Ecosystem]

In doing so, Omeka also helps advance the convergence and communication between librarians, archivists, museum professionals, and scholars that the digital age has sparked, allowing LAM professionals to participate more fully in the scholarship of the humanities and humanists to bring sophisticated information management techniques to their scholarship.

Which brings us back to the short answer. There really is no competition.

One Week | One Tool: Interim Report

As promised on Twitter, I’m sharing the report (with a few minor copyedits and corrections) I submitted this week to NEH on One Week | One Tool. This is an interim report, which means there are plenty of questions that remain unanswered. The grant continues for another year, during which time the One Week | One Tool crew will be working to support and extend their work together. I’m sure I’ll be blogging about their progress as we go, but at the very least I’ll post again with the final report next summer.

Executive Summary

One Week | One Tool represents a groundbreaking experiment in digital humanities training and digital humanities tool building. Culminating with the institute held July 25 – July 31, 2010 at the Center for History and New Media (CHNM) at George Mason University and the institute participants’ successful construction and release, in seven days, of a completely new open source software product, One Week | One Tool has made significant strides in proving its central claims: 1) that learning by doing is an important and effective part of digital humanities training; 2) that the traditional NEH summer institute can be adapted to accommodate this kind of practical digital humanities pedagogy; and 3) that digital humanities tools can be built more quickly and affordably than common practice would suggest. The second year of the project will seek to reinforce these claims and continue to advance participant learning through ongoing engagement and further development of the tool that was built during their week at CHNM—Anthologize.

Recruitment

The first task of the One Week | One Tool team was to publicize the institute. After dates were chosen, we developed a simple website in the style of an Old West poster to call for proposals. The call for proposals was issued in early February and closed in mid-March. To publicize the call, we leveraged CHNMs extensive outreach networks among digital humanities bloggers and on Twitter, where the announcement generated significant attention and excitement. Applicants were asked to answer three questions: 1) What skills/experiences/interests you think are most important to building a successful tool? 2) Which of these skills/experiences/interests you will bring to the barn raising? 3) What you think you will get out of attending that will help you in future pursuits? From this call, we received 48 formal applications and approximately another dozen serious expressions of interest.

The selection process was remarkably difficult. At least 35 of the 48 applicants were perfectly qualified to attend. To differentiate among them, we stuck to the criteria we outlined in our original proposal and laid out in the call. Applicants were chosen not on the basis of specific qualifications (e.g. a higher degree or particular skill set), but on evidence of teamwork, patience, flexibility, and resourcefulness (such as a history of picking up a programming language on one’s own). We were also looking to assemble a diverse group who together would possess the entire range of skills necessary to conceive, manage, build, and disseminate a tools project. The final group represented a broad range of scholars, students, librarians, museum professionals, developers, user interaction designers, bloggers, and project managers. They were also relatively diverse in terms of gender (4 women, 8 men) and seniority (ranging from a recently graduated college student to a tenured faculty member). Given the importance of intra-team dynamics to the success of software development projects, we took pains to introduce participants to one another via Twitter in the weeks after their acceptance so that they could begin establishing a sense of camaraderie ahead of their intense week of working together in July.

The Institute

Institute participants arrived on Sunday, July 25, 2010 for a kick-off meeting at George Mason University’s brand new Mason Inn and Conference Center, which served as the participants’ home away from home during One Week | One Tool. Participants’ transportation and lodging were arranged and paid ahead of time, with an additional $1000 stipend provided to each participant as an honorarium and to cover any incidentals. After a round of personal and professional introductions, project director Tom Scheinfeldt provided a brief introduction to CHNM and some of the core values CHNM brings to its open source software development work. Particular emphasis was placed on the value of "use," that the best measure of a tool’s success is its uptake and actual use by its intended audience. The first evening concluded with a brief discussion of participant and organizer expectations and an exhortation to get a good night’s sleep.

Monday was originally designed as the "teaching" phase of One Week | One Tool, during which CHNM staff members would provide participants with some lessons in software development best practices. This was ultimately the least successful portion of the program. Although introductory talks on technical aspects of software development (Jeremy Boggs), outreach mechanisms and community building (Trevor Owens), and the state of the art of digital humanities tools (Dan Cohen) were well received, participants were eager to get down to brass tacks, and we made a strategic decision to cut short the lectures and begin brainstorming tool choices a half day early on Monday afternoon.

Brainstorming continued through Monday evening and into Tuesday morning. By mid-morning on Tuesday, the group had proposed dozens of possible directions for the week’s tool building. By lunchtime, it had distilled those ideas down to six possible candidates. Over lunch, the group asked followers on Twitter to vote on the six choices. Well over 50 outside observers recorded their preferences. Taking this outside feedback into account, the group conducted two rounds of voting of its own, making a final consensus decision by mid-afternoon on Tuesday.

Work then turned to choosing roles and responsibilities. With guidance from CHNM staff, by Tuesday evening, participants had arranged themselves into three teams: Development, User Experience, and Outreach. Work began immediately, with developers making choices about encoding and architecture, user experience team members outlining potential use cases, and outreach staff researching the competitive marketplace and writing website copy.

Wednesday, Thursday, and Friday were each long days of code, design, and writing. The group quickly established a daily routine, which started with an all-project check-in meeting at CHNM’s offices at 10:00 a.m., was punctuated by a return to the Mason Inn at about 6:00 p.m., and ended with yet more work
at the hotel bar, usually until well past closing. Communication, leadership, and even membership among the teams were fluid, with teams spontaneously reconfiguring as particular skills were required for particular tasks. Moreover, throughout this "doing" phase, Tom, Dan, Jeremy, and Trevor encouraged additional CHNM staff—including Sharon Leon, Sheila Brennan, Ammon Shepherd, and John Flatness—to be available to help participants solve problems and make tough decisions. By Saturday morning, the One Week | One Tool team had designed and built the software; established an open code repository, a ticketing and bug tracking system, and a set of open source community development channels; and mounted an outreach and marketing campaign that consisted of an original name, logo, and website, as well as promotional bookmarks and stickers, a CafePress storefront, a formal press release, a media contact sheet, a set of public use cases, an FAQ page, and other end-user support channels.

During the course of the week, several members of the team "live blogged" and Tweeted (using the hashtag #oneweek) about this process, but they did so without giving away the final choice of tool, which served to create a buzz about the launch among potential users in the digital humanities community. Between July 25th and August 1st, hundreds of tweets were tagged #oneweek, mostly by outside observers, a measure of the extent to which One Week | One Tool captured the imagination of the digital humanities community. The tool the group produced, Anthologize, was launched on Tuesday, August 3, 2010 with a live video episode of CHNM’s popular Digital Campus podcast. More than 125 people took time out of their work day to tune in to the live announcement. In the days following the announcement, One Week | One Tool and the Anthologize were featured by Atlantic.com, Read Write Web, the Chronicle of Higher Education, and dozens of digital humanities blogs. As one external commentator put it, Anthologize and One Week | One Tool experiment had "set the DH world abuzz."

Anthologize

Anthologize is a free, open-source plugin that transforms WordPress 3.0 into a platform for publishing electronic texts. Anthologize lets users grab posts from their WordPress blog, import feeds from external sites, or create new content directly within Anthologize. Users can then outline, order, and edit their work, crafting it into a single volume for export in several formats, including PDF, ePUB, and TEI. Among Anthologize’s projected users are scholars (to edit anthologies of thematically related blog posts or publish conference proceedings), teachers (to edit student class work into e-portfolios or organize course reading packs), and cultural institutions (to publish exhibit books or donor gift books). Directions for future development include additional export formats, improved importing of external web content, footnote support, and integrating blog comments into the Anthologize editorial workflow.

Learning Outcomes

We are still collecting survey responses and assessing the results, but early on it is clear that One Week | One Tool was a positive learning experience for the participants. Unlike many curriculum-based institutes, the experiences and therefore the learning outcomes at One Week | One Tool varied widely among the participants depending on their team membership and on the skills they brought to the institute. Nevertheless, an initial analysis of participant survey responses reveals some commons themes. Among them:

  • Most participants responded that they learned about collaboration, leadership, and team building. Doug Knox pointed to the "self-taught lessons in group dynamics for a team of pragmatic collaborative autodidacts" he took from One Week | One Tool. As one participant responded, those lessons included "the kind of flexibility, trust, humility, and perseverance that is necessary to take on a relatively big project in a short period of time." In a post titled "Unexpected leadership," Boone Gorges echoed these lessons, writing "leadership doesn’t work without humility and trust." Effie Kapsalis described that same lesson plainly on the Smithsonian 2.0 blog: "Trust. Period."
  • Related to this were the lessons in decision making and calculated risk that most participants said they took away. As one participant wrote, "the experience really made me understand how much fear of acting alone can stall development and how trusting the emergent properties of the system can really lead to fantastic results." Jana Remy wrote in a related vein on her blog, "…one of the most important things we’ve learned through this workshop is the importance of calculated risk. It’s risky to forge forward with a digital project without months of planning, coding, and testing. It’s risky to trust near-strangers to deliver on such a tight deadline…. Our team selected one of the more daring choices available for our project. We were ready to be bold and to dream big. Even if the rest of the world doesn’t see our tool’s potential to be as earthshaking as we do, the process of manifesting our vision for this tool has been a valuable lesson in and of itself, and will certainly carry through to our future endeavors."
  • Several participants responded that they learned about outreach methods, marketing, and dissemination of digital humanities products. As one participant said, "I really found the information on how to manage publicity and outreach extremely useful, and I was completely stunned by the results…."
  • Several participants said they learned particular technologies (e.g. WordPress and Git) and practical lessons in open source software development best practices: "I also think I came to understand a bit more about how agile methodologies really work," remarked one participant.
  • Some participants pointed to their improved understanding of "what constitutes a full end-to-end development cycle." Experienced programmers and project managers, even those who entered the week with hundreds of thousands of lines of code under their belts and long track records of successful digital humanities work, responded that they learned about the differe
    nces between building a tool "from conception to roll-out" as they did at One Week | One Tool and the ad-hoc or task-specific development they do in the normal course of their work.

Every participant that responded to our survey said that One Week | One Tool met or exceeded his or her expectations, that it met its stated goals, that the experience would advance his or her career objectives, and that the model of learning by doing was effective. There were, however, at least two criticisms that were repeated by several participants. First, as mentioned above, most participants would have preferred to cut the Monday lecture portion of the program shorter, something we addressed on the spot and will keep in mind for any possible repeat events. Second, at least two people wanted to see more learning from fellow team members. The fast paced development cycle too often forced participants to keep their noses to the grindstone and opportunities for cross-pollination and peer-to-peer learning were sometimes missed. In any repeat performance of One Week | One Tool we will take seriously one participant’s observation that "…the group itself would have benefited from a more concerted effort to mix up knowledge multilaterally. There was some tension between working in small teams to get work done and making sure we had informal chances to share a sense across groups about the state of progress and the development of our sense of purpose. There were in fact essential unplanned lateral communications in all directions, and the bar was especially important in that. It worked, but there could be room to make it a more reflective process. We should have been teaching our strengths as well as contributing them, and apprenticing in our less-strong areas."

Yet in discussing One Week | One Tool’s learning outcomes, it is also important to note that, perhaps unlike more traditional institutes, the learning appears to have extended well beyond the twelve participants who traveled to Fairfax. This possibly unique aspect of One Week | One Tool results from the fact that: 1) it was an event, and 2) it produced a product for widespread distribution and use. As Tim Carmody posted on Snarkmarket, One Week | One Tool was a "generative web event," an "ongoing communal broadcast." Because it took place over a limited and clearly delineated time period, because it posited a provocative, easy-to-grasp, and unlikely challenge (academics build something in a week?), because it maintained an air of secrecy, and because it was widely publicized, One Week | One Tool was able not only to create "buzz" but to provoke conversation and discussion of serious issues among a broad range digital humanities scholars who could use their common experience of One Week | One Tool as a touchstone for debate. Two examples of this kind of broader discussion are ongoing exchanges about the nature of electronic writing and its relationship to the printed page and about the relative merits of pre- versus post-launch user studies.

Next Steps

Over the next year, the original group of twelve participants will continue to develop the tool from remote locations around the country, forming the core of an open source developer and user community that they will build and support. Indeed, the team has already developed and released a "point release" version 0.4 in the time since they left Fairfax. During the next ten months, the group will fix bugs in the software and add new features. It will continue to disseminate the software through online outreach and in-person conference presentations. As part of the group’s training in digital humanities software sustainability, it will also work with staff at CHNM to write grant proposals for additional funding and implement cost recovery mechanisms where appropriate. In June 2011, the group will travel back to Fairfax for THATCamp 2011 to assess the progress of the past year, gather additional feedback from community members, and make decisions about future development and support of Anthologize.

Conclusion

Overall, we are pleased with the progress of the One Week | One Tool project. The main learning objective of the project was to teach software development and deployment skills to a group of diverse group of digital humanists. As explained to participants on the first evening of the institute, we believe the best measure of the success of a tool is its use by and usefulness to its intended audience. By extension, the best measure of whether a group of people have learned to build successful tools is whether the tool they built is actually useful to and used by its audience. Early indications are good. In less than ten days the Anthologize website has received 232,000 hits, 75,000 page views, and 13,000 unique visitors, and the Anthologize software has been downloaded more than 2,500 times. We have high hopes for the coming year, and we will continue to keep track of these numbers and follow the projects that use Anthologize.

Lessons from One Week | One Tool – Part 3, Serendipity

Over the past few months, several people—including several participants themselves—have asked me how we chose the One Week | One Tool crew. We had about 50 applicants. Nearly all of them were perfectly qualified to attend. This made the selection process exceedingly difficult. I have no doubt we could have ended up with another group of twelve and been equally successful. Indeed, I have often joked that with the applicant pool we got we could easily have done “Three Weeks | Three Tools.”

In the end, the uniformly high quality of our applicant pool meant we had to make our choices on largely subjective criteria. Who showed the most enthusiasm? Who showed the most willingness to collaborate? Who seemed open minded? Whose writing style showed clarity of thought and energy? Who seemed like the hardest workers? Who seemed eager to learn? Whose seemed like a quick study?

One important thing to note is that we didn’t pick for particular technical skills. Of course we wanted a good mix: a team full of UI specialists or outreach experts wouldn’t have worked. But we didn’t select for PHP, Ruby, Java, TEI, or any other technology. We assumed that if we picked good people with a range of skills, even if those skills were all over the map, we’d end up with something interesting. I think we have.

As it turns out, we have ended up with something even more interesting because of that diversity of skills. Boone said something very telling at the bar on Thursday night: Anthologize probably couldn’t have been built without One Week | One Tool. A single shop wouldn’t have had the necessary range of skills to do it. I know CHNM couldn’t have done it alone. Sure, we have the PHP and JavaScript chops (although not the intimate knowledge of WordPress Boone brought to the table). But we certainly don’t have deep knowledge of TEI and XSLT the team needed to produce Anthologize’s rich, clean outputs. Nor, I suspect, would we even have hit upon TEI as a solution to that particular problem.

There are lessons here for hiring. Pick the smartest people. The best writers. The hardest workers. Pick people with proven track records of working well in teams. People with lots of energy. People who approach heavy workloads with clear thinking and good humor. People who’ve shown aptitude for picking up new technical skills on their own.

These people may not know what you need them to know on Day 1. But they will work hard to learn it. They’ll also bring a host of additional skills you didn’t think you needed, but will be happy to have once they’re there. Having these additional skills on tap may even let you take your work in directions you couldn’t have otherwise imagined.

#oneweek #buildsomething

Lessons from One Week | One Tool – Part 2, Use

For all the emphasis on the tool itself, the primary aim of One Week | One Tool is not tool building, it’s education. One Week | One Tool is funded by NEH under the the Institutes for Advanced Topics in Digital Humanities (IATDH) program. IATDH grants “support national or regional (multistate) training programs for scholars and advanced graduate students to broaden and extend their knowledge of digital humanities.” Thus training is the criteria by which One Week | One Tool will ultimately be judged.

A key argument of One Week | One Tool is that learning digital humanities consists primarily in doing digital humanities, that digital humanities is a hands-on kind of thing, that to learn tool building you have to do some tool building. At the same time, we recognize that there’s a place for instruction of the hands-off sort. To that end, the first 18 hours or so of One Week | One Tool (essentially from Sunday night until mid-afternoon on Monday) were reserved for presentations by CHNM staff. Jeremy offered a practical introduction to software development best practices and tools. Trevor described the range of outreach strategies we have employed on projects like Zotero, Omeka, and the National History Education Clearinghouse. Dan provided the view from 30,000 feet with thoughts on the state of the art and near future of digital humanities software development. I kicked things off on Sunday with a brief introduction to CHNM and our tool building philosophy. Several strains of thought and practice inform our work at CHNM—public history, cultural history, radical democracy, dot.com atmospherics, and more—but to keep things simple I summed up our tool building philosophy in one word: use.

Here is more or less what I told the crew.

At CHNM we judge our tools by one key metric above all others: use. Successful tools are tools that are used. The databases of Sourceforge and Google Code are littered with interesting, even useful, but unused open source tools. Academic software projects are no exception. Every year NSF, NIH, and now NEH and IMLS award grants for scholarly software development. In recent years, the funding guidelines have stipulated that this software be made freely available under open source licenses. Much of the software produced by these programs is good and useful code. But little of it is actually used.

There are several reasons for this. Many efforts are focused narrowly on the problems of a particular researcher or lab. While the code produced by these researchers proves useful for solving their particular problems, even when released, it hasn’t been designed to be generally applicable to the needs of other researchers in the field. It is, in effect, a one-off tool released as open source. But open source code alone does not constitute an open source project.

Other projects build generalized tools that may be of potential use to other researchers. But few make the necessary investment in outreach and, yes, marketing to make potential users aware of the tool. It is for this reason, among others, that we see so much duplication of effort and functionality in scholarly software projects.

Building a user community is the first prerequisite to building a successful open source software project. The success of software is judged by its use. The universal assessment that iTunes is a hit and Zune is a flop is not based on the quality of the code or even the elegance or potential usefulness of the experience. It’s based on the fact that everybody uses iTunes and nobody uses Zune. This is not to say that software has to have millions of users to be successful. But it is to say that successful software is used by large swath of its potential users. To be sure, the total population of potential users of cultural heritage mapping tools is much smaller than the total population of potential users of digital media playback software. But any open source software project’s goal should be use by as many of its potential users as possible. In any case, we should aim to have our software used by as many cultural heritage institutions and digital humanists as possible.

Moreover, a large and enthusiastic user base is key to a successful open source software project’s continued success. If people use a product, they will invest in that product. They will provide valuable user testing. They will support the project in its efforts to secure financial support. They will help market the product, creating a virtuous circle. Sustainability, even for free software, is grounded in a committed customer base.

Related to building a user community is building an open source developer community. Some number of users will have the inclination, the skills, and the commitment to the project to help on the level of code. This percentage will be very small, of course, less than one percent, which is another reason to build a large user base. But this small group of code contributors and volunteer developers forms the core of most successful open source projects. They find and fix bugs. They provide end user support. They write documentation. They add new features and functionality. They provide vision and critical assessment. They constitute a ready-made pool of job candidates if a core paid developer leaves a project.

This developer community is a project’s best chance at sustainability, and collaboration at the developer level, rather than collaboration at the institution or administrator level, is usually key to a scholarly open source project’s lasting success. Getting provosts, deans, and directors from partner institutions to commit FTE’s and other resources to a project is very welcome—we’d love some commitments of this sort for the tool we built last week. But it’s not where the strength of a collaboration will be located. Individual developers, who commit their time, effort, ideas, code, heart and soul to a project, are the ones who will keep something going when money and institutional interest runs out.

A developer community does not develop on its own, of course. It requires support. First and foremost, a developer community needs open communication channels—an active IRC channel and listserv, for example—something which, in the case of a university of library-based project, means a group of responsive staff developers on other end. Community developers need profitable access to the project’s development roadmap so they know where best to contribute their efforts. They need well-documented and thoughtfully-designed APIs. They need technical entry points, things such as a plugin architecture where they can hone their chops on small bits of functionality before digging into the core code base. Most importantly, community developers need a sense of community, a sense of shared purpose, and a sense that their volunteer contributions are valued. All of this has to be planned, managed, and built into the software architecture.

This philosophy of use is core to CHNM’s vision of open source software for scholarship and cultural heritage. The tool the crew of One Week | One Tool developed—like Omeka and Zotero before it—should be case in point. It was chosen with clear audiences in mind. It was built on approachable technologies and engineered to be extensible. It’s outreach plan and feedback channels are designed to encourage broad participation. When it’s released tomorrow, I think you’ll see it is a tool to be used.

#oneweek #buildsomething