How to set up a shared reference library for your research lab

To set up a shared reference library for a lab, make a few decisions before you choose or configure any software: whether you want one library per project or one for the whole lab, who is allowed to add and edit, how papers are tagged, and who owns the library when people leave. Then create the shared library in your reference manager, seed it with the papers the lab already relies on, and write the conventions on a single page that every new member reads. The tool matters less than the agreement.

Why a lab needs one

Without a shared library, each person keeps a private collection, and the lab pays for it repeatedly. New students spend their first months rebuilding a reading list that already exists in three other people's accounts. Co-authors cite different versions of the same paper, one the preprint and one the published article. Manuscripts end up with mixed reference lists that someone has to reconcile by hand. And when a postdoc leaves, the collection they built over four years leaves with them.

A shared library fixes this by giving the group one agreed set of records: the same papers, with the same metadata, that everyone reads from and cites from.

Decide the structure: per project or per lab

This is the decision that shapes everything else. There are three workable patterns.

• One library for the whole lab. Simple to explain and good for onboarding, because everything is in one place. It becomes noisy as it grows, and everyone can see and change everything.
• One library per project. Each paper, grant or thesis has its own library, shared with the people working on it. It stays relevant and can include outside collaborators without exposing the rest of the lab's work. The cost is that a paper used in three projects is stored three times.
• A hybrid. A small lab-wide "core" library of the methods papers and key references everyone needs, plus one library per active project. For most labs of more than four or five people this is the pattern that lasts.

If you are unsure, start with the hybrid, and keep the core library deliberately small: the papers you would hand to a new student in their first month.

Decide who can add, edit and delete

Open editing keeps a library alive, because adding a paper takes seconds and nobody has to ask. It also means anyone can delete or overwrite a record. Curated editing, where one or two people add on behalf of the group, keeps the library clean and usually keeps it out of date.

A sensible default: everyone on a project can add and edit in that project's library, the core library is edited by a small number of people, and only the owner or an administrator can delete in bulk or change settings. Name one person as the librarian for each library. The role is light, about fifteen minutes a month merging duplicates and tidying tags, but it needs to be someone's job.

Agree naming and tagging conventions

A shared library is only searchable if people describe papers the same way. Write the conventions down before the library has a hundred papers in it, not after.

• A short tag vocabulary: ten to twenty tags, written in a list, covering topics, methods and study types. Decide on lower case or title case, and singular or plural, once.
• No personal status tags in shared space. "to read" means something different for each person. Keep reading status in your own account, or prefix it with initials.
• Folder or collection names that match how the lab talks: project names, chapter names or aims of the grant.
• A rule for versions: when the published article exists, it replaces the preprint.
• A rule for identifiers: every record has a DOI or PubMed ID where one exists. Identifiers are what make duplicate detection and citation formatting work.
• If you keep PDF files outside the reference manager, one file-name pattern, such as FirstAuthor_Year_ShortTitle.

Handle duplicates and PDFs carefully

Duplicates are the main way shared libraries decay. Two people add the same paper a week apart, each attaches notes to their own copy, and the manuscript ends up citing both. Prevent it at the point of entry: add papers by DOI or PubMed ID rather than by typing titles, search before adding, and have the librarian run the reference manager's duplicate check on a schedule.

PDFs need more thought than references. Sharing a citation record raises no rights question. Sharing the full text of a paper can. What you may share depends on the article's license, your institution's subscriptions and local copyright law, so treat this as a point to check, not to assume:

• Open-access articles under a license that permits sharing can generally be stored in a group library.
• For subscription articles, the cautious approach is to share the reference and let each member get the full text through their own institutional access.
• Keep shared libraries that contain full text private to the group, never public.
• Take extra care when a library includes collaborators from other institutions, who may not hold the same subscriptions.
• If in doubt, ask your university library. They answer this question often.

Plan for people joining and leaving

Labs change every year, so the library has to survive turnover. For new members, a one-page guide is enough: how to get access, the tag list, how to add a paper, the PDF policy and who the librarian is. Add "invite to the shared library" to the same checklist as building access and email lists.

For departures, the important questions are ownership and access. The library should be owned by an account that will not leave: the principal investigator, or a lab account, not a student who graduates in two years. If the owner does leave, transfer ownership before they go. Decide in advance whether alumni keep access, and make sure anything a departing member holds only in a personal library is copied into the shared one before their last day.

How group libraries work in common reference managers

Most reference managers offer some form of shared library, and the settings map closely onto the decisions above. Two examples, described from the vendors' own documentation:

• Zotero has group libraries, which are separate from each member's personal library. A group can be private, public with closed membership, or public with open membership. Each group has members, administrators and an owner, and its settings control whether any member or only administrators can edit the library and its files. Ownership can be transferred. Items dragged from a personal library into a group are separate copies, so later edits to one do not change the other, and a group's stored files count toward the group owner's storage, not the other members'.
• EndNote lets you share a synced library with colleagues, giving each person either "Read & Write" or "Read Only" access, and you can also share a single group of references instead of the whole library.

Whichever tool you use, look for the same things in its settings: who can join, who can edit, whether files are shared along with references, and who owns the library. Features change, so check the current documentation before you commit the lab to a setup.

A setup checklist

1. Choose the structure: lab-wide, per project, or a small core plus projects.
2. Choose an owner account that will outlast any one student.
3. Set who can add, edit and delete, and name a librarian.
4. Write the tag list and the rules for versions and identifiers on one page.
5. Agree the PDF policy with your institution's guidance in mind.
6. Seed the library with the lab's key papers, added by DOI.
7. Invite members, and add the library to your onboarding and leaving checklists.
8. Review duplicates and tags once a month.

How this looks in Mosaic

Mosaic follows the per-project pattern. A lab is a workspace, and the workspace holds projects, each with its own library, documents, tasks and briefing of new papers. Papers are added by DOI, PubMed ID, link or PDF, and Mosaic tells you when a paper is already in the project's library instead of adding it twice. Within a library you can use folders, tags and "Key sources" to mark the papers the group relies on (Organize papers with folders and key sources).

Access is set by role. A workspace has an owner, admins and members. Owners and admins invite people by email, and each invitation link works only for the address it was sent to. A member can be a full member, who sees every project, or a collaborator, who sees only the projects you choose, and for each you pick the sections they get: Library, Documents, Tasks and Briefing. That makes it straightforward to add an outside co-author to one project without opening the rest of the lab's work. Roles and access lists what each role can do. When someone leaves, the owner removes them and their access ends immediately, while their comments and tasks stay.

If the lab's papers are in Zotero or Mendeley today, you can import collections, folders or single items into a project. It is a one-time copy, not a sync, and notes and annotations stay in the original tool; see Mosaic and Zotero and how the two compare. Mosaic is in an invite-only beta with a waitlist. For organizing your own papers before you share them, read how to organize research papers.