Main content



Loading wiki pages...

Wiki Version:
**The promise of open science collaboration** Done well, open collaboration can radically transform scientific practice. Scientific expertise is distributed across many minds, but scientific problems are rarely localized to the existing expertise of one or a few minds. Broadcasting problems openly increases the odds a person with the right expertise will see it and be able to solve it easily. This means that solutions can be identified quickly rather than requiring lots of additional self-training by the idea originator (who may not even know what training to get). Likewise, with many people drawing on distinct expertise, novel solutions may emerge rapidly that would not have been identified by individuals or small groups. In addition to better and faster problem-solving, open projects can be more ambitious because more areas of expertise (and hands) can contribute to a problem without as much time or resource investment by any individual. For example, it is much easier to contribute on issues that are central to one's skills/expertise than to build new expertise. Simultaneous knowledge gain for each contributor can be rapid because they learn from each other's contributions on a shared problem. Finally, there are many ways to contribute productively on large-scale projects--data coding, collection, analysis, writing, conceptualization, design, coordination, etc. In such projects, all contributions are essential and valued, meaning that many areas and levels of expertise can contribute productively together--from senior expert to citizen scientist. **How open science collaboration can work** There are multiple threats that will kill an open science group--particularly in managing the collective effort with the constraints of individual contributions. [Michael Nielsen][1] summarizes these very well in [Reinventing Discovery][2]. A successful open science collaboration must: (a) modularize: split up the tasks into independent components, (b) encourage small contributions, (c) develop a well-structured information commons, and (d) maintain individual incentives to participate. These lower the barriers to entry for new contributors, and maximize the range of expertise input potential. Individuals should see that getting involved in a project can be done easily, even if the project is underway. Ideally, it should be possible to make meaningful contributions with whatever time and interest is available. The Open Science Collaboration (OSC) involves continuously refining these practices as much as actually executing the projects themselves. **What is the Open Science Collaboration?** The Open Science Collaboration (OSC) operates through the [Open Science Framework][3] (OSF). The OSC is a breeding ground for open, [[collaborative projects]] for whoever contributes to them. There is no claim - implied or explicit - that any given project in the OSC is "endorsed" by any given OSC contributor. It would be perfectly reasonable, for example, to have two projects that are competing in conception, design and/or conclusion that develop in the OSC with independent sets of contributors. OSC projects can emerge and thrive or die depending on the interests and engagement by members of the OSC. That said, the OSC has community standards for how project evolve and how authorship is determined. These standards facilitate project development and reduce problems and conflicts in [[collaborative projects]]. Community standards are not about what kinds of projects are appropriate, but how to manage the development of [[collaborative projects]] in an open model. **How do projects develop in the Open Science Collaboration?** If a project is suggested in the OSC [discussion group][6], then it is an "open project" in the sense that it is possible for anyone in OSC to contribute to and develop the idea, and perhaps turn it into an active project with a target product (e.g., tool, infrastructure, research article). There are some qualifications and elaborations: 1. Project coordinators are necessary and functional for project development and management. Most of the time, the coordinator(s) will emerge naturally. For example, it would be common for the originator of the project idea to become the coordinator. If a project lead does not emerge, it is likely that the project will die (perhaps for the best). 2. A project coordinator has some organizational responsibility and authority for keeping the [[collaborative projects]] moving. That might include setting deadlines for getting involved and making contributions, or defining and negotiating the roles of the contributing members on the project. The project lead has responsibility to make the expectations for the project explicit (even if they are decided collectively), so that all members of the team have a shared understanding of the project and their contribution. 3. If a project appears to be dying within OSC, a member can post to the OSC [discussion group][7] indicating that they would like to pursue the project independently of OSC. If there is ever a dispute, the OSC community can discuss collectively how to resolve it. **How is authorship determined for Open Science Collaboration projects?** Once it becomes clear that ideas are turning into [[collaborative projects]], the project coordinator or group of initial contributors should explicitly define how authorship will be determined. Critically, this discussion should occur before any contributor invests substantial time and resources in the project. All contributors should explicitly understand and agree to the authorship terms prior to putting substantial effort into any project. There are at least two decisions to make in the authorship discussion. The first is the threshold for earning authorship. The second is how authorship will be presented in the eventual report(s) or communications of the tool/infrastructure origins. One option is to have the listed author be "The Open Science Collaboration" and present the individual authors in a footnote or appendix alphabetically. Another option is to have the authors listed in the traditional publishing format--first author is the project lead, trailing authors by contribution, last author sometimes being the senior author of the primary laboratory. In this case especially, it is critical that the authorship order and contribution expectations for each contributor to be defined in advance. The advantage of using "The Open Science Collaboration" as the author is that the project team need not wait for slow or non-responsive contributors. Also the project team is not concerned with whether a person earned their particular position in the authorship order. The only question is whether they met the minimum threshold for authorship, which was defined in advance. Contributions beyond the minimum threshold are rewarded with enhanced reputation (much more important than authorship order anyway). The advantage of the traditional publishing format is that it provides the familiar heuristic to guess about each author's contribution. Decisions about which authorship strategy to use are left to the people involved in that particular project. The key is to establish shared understanding of authorship before any extensive work is done. **How do contributors get credit for their work on Open Science Collaboration projects?** For projects with traditional publishing authorship formats, the reports, tools, or infrastructure are cited on the vita or resume as is standard practice. For projects that are published with "The Open Science Collaboration" as primary author, contributors include the citation on their resume or vita and can add brief explanation of their contribution, if desired. Notes about nature of contribution might be particularly relevant for junior scholars that need to make clear their contributions for hiring and career advancement. Further, as an open project, reputation is vitally important. Collaborators will know who made important contributions and how. As such, OSC members should be explicit and vocal about giving credit to individual members when credit is deserved - not just within the group, but to others. Junior scholars should not be shy about asking more senior scholars in OSC for letters of recommendation or other support. In short, contributions should be recognized, credited, and valued. **How does Open Science Collaboration manage free-riders and disagreements?** Transparency in project activities and up-front communication about expectations for each project will minimize free-riding and other common conflicts that emerge in collaborative research. With clear communication, potential contributors will have a clear understanding about the responsibilities and rewards for getting involved in any particular project. With transparency, free-riding will be evident to all group members causing loss to reputation. Even so, conflicts will occur. Project teams resolve conflicts internally among collaborators. If unsuccessful, project teams can communicate the nature of the conflict to the OSC [discussion group][8] for resolution advice. [1]: [2]: [3]: [4]: [5]: [6]: [7]: [8]:
OSF does not support the use of Internet Explorer. For optimal performance, please switch to another browser.
This website relies on cookies to help provide a better user experience. By clicking Accept or continuing to use the site, you agree. For more information, see our Privacy Policy and information on cookie use.

Start managing your projects on the OSF today.

Free and easy to use, the Open Science Framework supports the entire research lifecycle: planning, execution, reporting, archiving, and discovery.