Outreach and Scholarly Software

A few months ago I had the distinct pleasure of sharing some of my experiences and thoughts on outreach and community building for scholarly software projects with the One Week One Tool team as part of the first two days of the summer institute. I was excited at the prospect of sharing my experience, but intimidated by the fact that so many of the participants had already done a considerable amount of work in this field. I like to think our outreach conversation went well!

With a little bit of time distancing myself from the actual event I thought I would work through some of the ideas I put forward to the group. My goal here is twofold, first I would like to share some of our discussion of software and community with folks who were not a part of the event and second I would be interested to hear from the participants about how my ideas did or didn’t resonate with the work they engaged in on anthologize. So below you will find 5 principles and 5 roles I see as critical to scholarly software outreach. I don’t by any means claim to have invented anything here, just trying to share my thoughts on practices. If you’re interested in a more extensive run down of the project I would suggest Tom’s interim report.

Trevor’s 5 Outreach Principles

1. Outreach sounds like it starts at the end, but it should be a bit more ever present. It starts with a conception of audiences. Who are the end users? Who can I get to promote this to those end users? Make this part of your upfront planing process.
2. Understand outreach as a value proposition for your end users. The more time and energy it takes to get your tool to do whatever it is supposed to do the better it’s payoff should be. Your competing for the end users attention and time. Those are scarce resources. Your tool’s site should establish the problem the tool solves and why this is a great way to solve that problem in as concise a way as possible.
3. If possible, leverage existing communities. At this point, whatever you are trying to work on has already been worked on. Are there some interesting open standards that have some solid work behind them? Are there some abandoned tools who’s users you could pick up? If you can offer a clear value proposition to an existing group you don’t need to start from scratch.
4. Spending time convincing people who convince people to use your tool can be far more effective than spending time convincing people to user your tool. This has always been the strategy on Zotero. The most effective parts of our outreach have been developing workshops to train folks to use the tool. There is a value proposition here too. If a tool really makes it, being able to teach someone how to use useful software is a credential.
5. Look more reputable. People are scared that software will eat their data. Aside from making sure that doesn’t happen, you should try your hardest to make people feel like you are going to stick around for a while. This means that the design of your site matters. Things that look slick, that have active news feeds, that identify who funded them and what the plan for the future is are going to make folks more comfortable. Having a solid reputation is a great goal, but you need to start somewhere, you might even consider connecting the project with things people trust.

Trevor’s Five Components of Outreach

I like to think about outreach as building and engaging with existing communities of software users, evangelists, and potential code contributors. In this view outreach involves at least five very different roles/tasks. Other folks might cut these up and organize them differently, in a big project there could be a range of folks taking on these roles, in a small project they might all fall to the same person.

1. Usability: If people are going to use the software you need to get a sense of how folks understand it. In my experience, starting with something like user personas in the initial design phases and pushing out functional software for public use and testing is great. In other cases it might make sense to do much more extensive testing.
2. Marketing and publicity: This part is what a lot of folks think of as core outreach activity. Spreading the word about your tool, trying to get it mentioned in the right places, giving talks at the kinds of meetings and conferences your potential users go to, getting coverage of your tool in the kinds of publications your potential users read. This is great stuff, you can’t ignore it. On the most basic level its about crafting a message and getting it out there through a blog or news section. If you pitch your story right you could get picked up by some real big deal blogs and generate some traffic to your tool.
3. User Guides and Documentation: After taking a quick look at your homepage the next stop for a lot of users is going to be your documentation. I think one of the biggest problems I see in different projects is that folks think of documentation as technical information and not as part of their outreach efforts. No matter how much you invest in getting people to visit your site, how much you put into getting an attractive homepage, it can all be for naught if you don’t make it as easy as possible for people to figure out how to do what they want to do with your too. The key point here is that documentation is not about describing what the software does it is about telling people how they can do what they want to do with your tool. While you might think the homepage of your site is the front, remember that web search means any page could be the first page someone sees.
4. User Advocacy: Once a project has users it also has people outside of the development team that want the tool to do something. Now, a lot of tools don’t ever get here, but when they do it is critical to try to role their interests and voice into the project. If you want users to stay around and become advocates you need to need to have someone advocating for their needs.
5. Sustainability: It’s a great word, and in the world of grant funded work it is, for good reason, THE big idea. If anyone is going to fund your project they want to know that they are not signing up to provide you with funding till the end of time. It is easy to gesture toward a user community as part of a sustainability plan, but it is much more difficult to turn people into users, users into promoters and coders, and those folks into a network that ultimately ensures a sustainable future for a tool.

So what do you think? Is this a reasonable way to think about outreach and scholarly software? Are there things missing from the picture? Are there things in here that you think shouldn’t be viewed as part of Outreach? For folks who participated in the One Week event, how did or didn’t these ideas come into play with Anthologize?

Works that shaped my ideas on users, software and community

1. Brown, D. (2006). Communicating Design: Developing Web Site Documentation for Design and Planning. New Riders Press.
2. Garrett, J. J. (2002). The Elements of User Experience: User-Centered Design for the Web. Peachpit Press.
3. Jin, L., Robey, D., & Boudreau, M. C. (2007). Beyond Development: A Research Agenda for Investigating Open Source Software User Communities. Information Resources Management Journal, 20(1), 68-80.
4. Krishnamurthy, S. (2005). Launching of Mozilla Firefox – A Case Study in Community-Led Marketing. URL http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.59.687