How to do open research: 5 basic principles

No readers like this yet.
How to do open research: 5 basic principles

Opensource.com

Some folks at UNICEF asked me to help them articulate a process for how to make their research projects (usually “is this program we want to do a feasible one?” or “what was the impact of this program we did?” into open content ones. Here’s what I wrote them back.
There are some pretty basic things that a researcher can do to make their work into an open content project. Here are a few.

1. Radical realtime transparency. Release all work in an editable format under a creative commons license as soon as it’s made. I’ll elaborate on each of those points in a bit more detail:

1a. Release all work. This means not just the finished/polished products, but the rough drafts, the incoherent notes, and the random scribblings as well. You can put disclaimers of “these are the rough things” at the top, and you don’t need to do announcements of the release of all your low-level work (except in weekly summaries) but they will let other people dig as far as they could possibly want to go on your activity in the space.

1b. In an editable format. No pdfs — wiki pages, plaintext in a version control repository, something Word (or better yet, .odt) files are marginally acceptable, but force you to become a merging bottleneck; it’s best to get as close as possible to people being able to edit not just the material, but also each other’s edits, themselves.

1c. Under a creative commons license. Use the same license as the final paper. UNICEF chose the CC-BY-SA license, which is good; the key point is to avoid the “noncommercial” and “no derivatives” restrictions, which are the non-open creative commons license variants. Remixability for all purposes is vital.

1d. As soon as it’s made. This means what it sounds like; push it as you do it, not after the fact as “background material” accompanying the finished paper. If you want people to help you along your journey, they need to know as accurately as possible where you are right now.

2. Make work findable. Have a central place where people can easily read the current status of the project in 1 minute or less, and where they can quickly navigate to all the materials you’ve created for it. The specific structure/format isn’t as important as having a clear structure to begin with; pick a schema and stick with it.

3. Make participation as low-barrier as possible. Whenever possible, don’t require logins or account creation. If you must use authentication of some sort, think about what accounts the people you want as collaborators are already likely to have (facebook? twitter/identi.ca? wikipedia? github?) and what platforms they’re already likely to be familiar with (do they know version control? word processing? English?) and in general try to make it possible for someone to go from “stumbled across your project” to “made a contribution” in as few seconds and clicks as possible.

4. Update in a regular rhythm. Weekly is usually good, but for some projects it may make sense to cycle more quickly or slowly. For those who need a rule of thumb, I’ll semi-arbitrarily say that you should have at least 5 updates throughout the life of your project, so a 2-month project might have weekly updates, a 2-week project would have daily updates, a 1-day project might have hourly updates, but a 1-year project might have bimonthly updates (though weekly updates will drive more participation). Pick a schedule, announce it, and stick to it; this is something that should be on the front of your “participation” homepage (from #2, “make work findable”) so that new people coming in know when the “next thing” is coming up that they can jump in on.

5. Reach out in backchannel to bring people to the public space. Email, go to conferences, tweet/dent, blog, sit down at coffee shops, go to marketplaces… go where the people are, and engage with them in their spaces as long as it takes for you to help them feel comfortable coming to yours. Basically, private conversations are necessary, but they’re necessary as a means towards the end of bringing people into a public and collaborative space. It’s like opening a new physical location for something like a bar or a library; you want everyone to end up in your space interacting with each other, so you go out and have individual conversations with them aimed towards getting them there.

 

This article was originally posted on Mel's blog.

Tags
User profile image.
Mel Chua is a contagiously enthusiastic hacker, writer, and educator with over a decade of teaching and curriculum development experience and a solid track record in leadership positions at Red Hat, One Laptop Per Child, Sugar Labs, Fedora, and other Free, Libre, and Open Source Software (FLOSS) communities.

2 Comments

very nice!
thanks!

on a somewhat related topic:
i want to try to get students to embrace your 1. for all they do, most importantly all projects they work on in teams.
the most important sub-point there is 1b (In an editable format) and second is 1d (As soon as it’s made).
this makes collaboration during a team-work much faster and nicer, and as a brainwashy kind of side-effect, gets them to udnerstand and love the open source way of doing things, and may make htem more likely to get into open source contribution in the long run. ;-)

Nice topic.
Tried to translate it into Traditional Chinese.
http://baroqueblender.blogspot.com/2012/05/5.html

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.