Behavior Research Methods
https://doi.org/10.3758/s13428-023-02161-x
DataPipe: Born‑open data collection for online experiments
Joshua R. de Leeuw1
Accepted: 2 June 2023
© The Psychonomic Society, Inc. 2023
Abstract
DataPipe (https://​pipe.​jspsy​ch.​org) is a tool that allows researchers to save data from a behavioral experiment directly to the Open
Science Framework. Researchers can configure data storage options for an experiment on the DataPipe website and then use the
DataPipe API to send data to the Open Science Framework from any Internet-connected experiment. DataPipe is free to use and open-
source. This paper describes the design of DataPipe and how it can help researchers adopt the practice of born-open data collection.
Keywords Open data · Open science · Data sharing
Behavioral experiments conducted over the Internet create
unique challenges for managing research data. Unlike labora-
tory experiments, online experiments must save data on stor-
age devices that are not directly connected to the computer
that is running the experiment. For example, a typical online
experiment uses a web server to send experiment code to a
participant's browser. The browser, on the participant's com-
puter, then runs the experiment and sends the data back to the
web server. Configuring a web server is not a task that most
researchers are familiar with. To make this easier for research-
ers, several open-source tools (e.g., JATOS, Lange et al., 2015;
PsiTurk, Gureckis et al., 2016; Pushkin, Hartshorne et al.,
2019; NivTurk, Zorowitz & Bennett, 2022) and commercial
platforms (e.g., Pavlovia, https://​www.​pavlo​via.​org; Gorilla,
https://​www.​goril​la.​sc; Cognition, https://​cogni​tion.​run; Open-
Lab, https://​open-​lab.​online) have been developed. While these
tools solve the basic data management problem, they also typi-
cally mimic the setup of a laboratory-based experiment. Data
are stored in a database or folder that only the research team
has access to. If a researcher wants to later publish the raw
data, they must transfer the files to a public repository.
Given that many researchers rely on this kind of tool, there
is an opportunity to help researchers improve their data man-
agement by designing tools that support best practices. While
there are many facets of good data management (Van der
Eynden et al., 2011), the focus of this article is open data.
* Joshua R. de Leeuw
jdeleeuw@vassar.edu
1
Department of Cognitive Science, Vassar College,
Poughkeepsie, NY, USA
Open data means that the data from an experiment are posted
in a repository that anyone can access (Murray-Rust, 2008).
There are many tools for sharing data in this way, including
the Open Science Framework (https://​osf.​io), ResearchBox
(https://​resea​rchbox.​org), figshare (https://​figsh​are.​com),
Dataverse (https://​datav​erse.​org), Databrary (https://​datab​
rary.​org), and more. These tools are typically free to use and
available to any researcher, yet many research articles are
published without making the data open. While there are no
discipline-wide estimates of the proportion of articles that
have open data, there are a few estimates from specific con-
texts in psychology that range from < 1 to 66% (Vanpaemel
et al., 2015; Obels et al., 2020; Hardwicke, et al., 2022).
There are costs and benefits to researchers for making data
available; achieving widespread adoption of the practice requires
getting the balance of these competing factors right. The factors
that encourage and discourage researchers to make their data
open include a diverse set of themes ranging from institutional
norms to individual beliefs (Zuiderwijk et al., 2020). At the insti-
tutional level, many journals have adopted data sharing policies
that require open data (Nosek et al., 2015)—though the enforce-
ment of and follow-through on such policies is sometimes lax
(Alsheikh-Ali et al., 2011; Hussey, 2023)—and/or recognition
for articles that elect to include open data (e.g., Kidwell et al.,
2016). Some research funders also incentivize data transparency
by requiring funded researchers to make their data open. The
National Institutes of Health in the United States, for example,
recently adopted such a policy (National Institutes of Health,
2020). There are also calls for collective action, such as research-
ers insisting on a minimal level of openness as a precondition for
peer review (Morey et al., 2016).
13
Vol.:(0123456789)

These institutional requirements are certainly one way to
increase data availability, but they don't apply to all circum-
stances. Some research is published in journals that does
not have (or does not effectively enforce) open data policies,
some research has no funder-based requirements, and not all
peer reviewers insist on making data open. If we want to push
towards broader adoption, we should think carefully about
why researchers choose to not make data available when they
are not required to. One of the most straightforward reasons is
that publishing a dataset in an open repository is an extra step
of work for researchers. Sometimes this step is quite simple
and other times it can be very time-consuming. It might be
reasonable to argue that this shouldn't be considered an extra
step—that it should be considered a foundational part of the
research—but existing incentives don't always align with this
view. So, in addition to further shifts in incentive structures,
another way that the practice can be encouraged is to make
it easier for researchers to share their data so that there is as
little additional effort required to make data open.
One way to do this is to create tools that automatically pub-
lish all new data to a repository that is, or can be easily made,
public. Rouder (2016) called this born-open data and described
such a system used in his laboratory. In his implementation,
data files are initially stored on a laboratory machine. These
files are saved in a directory that is configured as a Git reposi-
tory, which allows Git to track any changes made to the direc-
tory and synchronize the changes with a remote copy of the
repository. A scheduled script automatically synchronizes the
repositories once per day. A similar outcome could be achieved
by saving data files directly to a folder that synchronizes with a
cloud-based storage provider like Dropbox (Klein et al., 2018).
For data collected over the Internet, the same general approach
can be implemented by sending the data to a server that auto-
matically synchronizes the data with a public repository. Cous-
ineau (2021) documents an approach along these lines using
PHP scripts and Git, and provides a plugin for jsPsych that can
connect to these scripts.
While these are all excellent examples of ways to achieve
born open data, they require some effort and technical com-
fort on the part of the researcher to set up. Any researcher
could certainly follow the guide outlined by Rouder (2016)
or use the scripts published by Cousineau (2021), but this
would require additional time to set up relative to simply not
collecting data in this way. For a researcher who is already
committed to publishing all of their data in a public reposi-
tory, the initial investment in configuring these tools will
save time. However, for a researcher who is not planning to
publish their data in a repository, this setup is an extra task
and does not save the researcher time. This is particularly
true for online data collection because the simplest options
(e.g., saving all data files in a Dropbox folder) are not via-
ble when the data are collected on remote computers. To
maximize adoption of born-open data, the goal should be to
13
Behavior Research Methods
make it easier to collect born-open data than it is to collect
traditional closed data.
This paper describes DataPipe, a free and open-source
tool that allows researchers to send data directly from an
experiment to the Open Science Framework (OSF). Data-
Pipe is a hosted service that does not require the researcher
to configure their own system. Instead, researchers create
an account with DataPipe, configure the experiment using
the DataPipe website, and add a few lines of code to their
existing experiment. This makes the setup as easy or easier
than most existing methods for managing online data col-
lection. DataPipe is also not only free, but because of its
design, it allows researchers to host their online experi-
ments using free website providers. This means that a
researcher can run an online experiment entirely for free,
aside from any payments that are made to participants.
DataPipe can be used with any experiment software that
can make HTTP requests over the Internet. This includes
any experiment software that runs online, plus many lab-
based software packages as well.
DataPipe
DataPipe was developed with the goal of making born-open
data collection an attractive default option for researchers
running online experiments. I tried to accomplish this goal
in two ways. First, using DataPipe requires no experience
with managing data storage for online experiments. Hope-
fully, researchers who are new to online data collection will
view DataPipe as an accessible solution for data manage-
ment and thus be encouraged to adopt born-open data col-
lection. Second, experiments using DataPipe can be run
entirely for free—not only is the DataPipe service free, but
using DataPipe allows researchers to replace paid hosting
providers with free hosting providers because DataPipe
handles the functionality that a paid hosting provider would
offer. My hope is that the cost savings that DataPipe can
provide will attract users who have a working data manage-
ment solution but can save money by using DataPipe, and
thus also be encouraged to adopt born-open data collection.
In this section, I describe the design and implementation
of DataPipe with a focus on how it meets these two goals.
I do not provide a full tutorial of how to use DataPipe in
this paper, as specific details may change as the applica-
tion develops and updating this paper is not possible after
publication. Instead, a “getting started” guide is available
at https://​pipe.​jspsy​ch.​org/​getti​ng-​start​ed and detailed code
examples are provided inside the DataPipe experiment dash-
board after an experiment is created. Examples of using
DataPipe for a variety of experiment software (including
jsPsych, lab.js, and PsychoPy) are available at https://g​ ithub.​
com/​jspsy​ch/​datap​ipe-​examp​les.
Behavior Research Methods
Fig. 1  Overview of DataPipe's design. Researchers interact with the
DataPipe web application to configure an experiment. The parameters
of the experiment (e.g., which OSF component it connects to) are stored
Design
DataPipe is a service that operates between a researcher's
experiment and a researcher's project on the Open Science
Framework. There are two ways to interact with DataPipe: via a
web application that allows researchers to create and configure
experiments and via an API (Application Programming Inter-
face) that experiments can use to communicate with DataPipe.
To use DataPipe, a researcher logs in to the web application at
https://​pipe.​jspsy​ch.​org, configures a DataPipe experiment, and
then adds a few lines of code to their experiment software to
communicate with the API. When an experiment makes an API
request, DataPipe processes the request, performs the appropri-
ate action (e.g., uploading data to the OSF), and returns a mes-
sage indicating whether the request succeeded and if it failed,
why. Figure 1 visualizes the components of DataPipe and how
they interact with each other, experiments, and the OSF.
DataPipe currently supports three distinct interactions: sav-
ing text-based data files, saving binary data (e.g., an image)
encoded in base64, and sequential condition assignment.
These features are accessed through calls to DataPipe's API.
Text‑based data storage Most experiment data is recorded
in a text-based format, such as CSV or JSON. To save text-
based data using DataPipe, a researcher can send an API
request with the data and a filename. DataPipe will create
a new file containing the text on the OSF. In addition to
this simple pass-through storage mechanism, DataPipe also
supports basic data validation. Researchers can require that
in DataPipe's experiment configuration database. When an experiment
sends a data file to the DataPipe API, the API checks the configuration
of the experiment, processes the request, and sends the file to the OSF
any data sent to this endpoint be a valid CSV and/or JSON
file, and can also provide a list of variable names that must
appear in the data. If the validation fails, the file is rejected
by DataPipe. DataPipe also rejects a request if the filename
already exists on the OSF. This prevents research partici-
pants from overwriting existing data.
Binary file storage Occasionally experiments need to store non-
text based data, such as audio or video recordings. To save this
kind of data using DataPipe, a researcher can send the data
encoded in base64 format1, as well as a filename. DataPipe
will then decode the base64 representation into the original
filetype (e.g., .webm for a video recording from the participant's
camera) and post the resulting file on the OSF. Converting to
base64 format is a straightforward task in most programming
languages and some experiment software (e.g., jsPsych) will
automatically produce base64 representations of media record-
ings. One advantage of using DataPipe to save these data is that
the file conversion will happen automatically prior to posting
the data on the OSF, so users accessing the OSF repository will
be able to interact directly with the media content.
Condition assignment DataPipe supports sequential con-
dition assignment. Researchers can configure the number
of conditions in an experiment using the web application.
1
Base64 format encodes the data as a string using a vocabulary of
64 characters. We use base64 for non-text-based data because it is
easy to encode and decode the format in a variety of programming
languages and it enables transmission of the data as a text stream.
13

When DataPipe is queried for the condition, it returns the
next condition number in sequential order, resetting to 0
when the maximum number of conditions is reached. While
this feature is not directly relevant to using DataPipe as a
tool for born-open data, it does fill a need for researchers
who are trying to host their experiments without setting up
their own server. Any attempt at balanced condition assign-
ment in an online experiment requires some kind of server
to record which conditions participants have been assigned
to because participants are usually completing the experi-
ment in parallel. This feature is included in DataPipe to fill
a common need for researchers who are interested in using
DataPipe but need this simple form of condition assignment.
Experiment configuration In order to use the features
described above, researchers must configure an experiment
using the DataPipe web application (https://​pipe.​jspsyc​ h.o​ rg).
When creating a new experiment in DataPipe, the researcher
specifies the OSF project that will be used to store the data.
DataPipe then generates a new OSF data component inside
that project and uses this new component to store data.
Once an experiment is created on DataPipe, the researcher
can use the website dashboard to manage access to the dif-
ferent features. Each of the three features (text-based data
storage, base64-encoded data storage, and sequential condi-
tion assignment) can be enabled or disabled for an experi-
ment, giving the researcher full control over what kinds of
data can be written to the OSF component. Disabling unused
features and disabling all features when data collection is
complete can reduce the likelihood of malicious use (see
section on risks, below). Disabling data collection is also a
way to host an experiment online for demonstration purposes
without sending new data to the OSF.
In addition to disabling and enabling features, researchers
can configure several options. Researchers can set a cap on
the number of files that DataPipe will accept before rejecting
additional data. For text-based data collection, researchers
can set up validation rules for CSV and JSON data. These
rules (1) check if the text is a valid CSV and/or JSON string
and (2) check for a list of required variable names. This
allows researchers to ensure that data being written to the
OSF meets some minimum requirements, which reduces the
likelihood of spam data being saved to the OSF. A future
development goal is to allow for additional data validation
rules, like specifying a schema that data files must meet in
order to be considered valid.
Researchers who want to use the condition assignment
feature can configure the number of conditions in the exper-
iment. Currently, only sequential condition assignment is
supported (e.g., the first participant gets condition 0, the
second gets condition 1, etc.). This is better than pure ran-
dom assignment if the goal is to balance participants across
conditions, but it is not ideal. A future development goal is
13
Behavior Research Methods
to record completions by condition in the API so that condi-
tion assignment can be adaptive to dropouts. This is a tricky
problem to solve in online experiments because participants
are often completing the experiment at the same time, and
condition assignments have to be made before completion
information is known.
Are there limitations on how many files or how much data
can be transferred using DataPipe? DataPipe has no restric-
tions on the number of files or the size of the data. Practi-
cally speaking, it may be unrealistic to transfer very large
files using DataPipe because participants must keep their
browser window open while the files are being uploaded
and large files may require a long upload. Most text-based
data is not large and even medium-sized files like audio or
video recordings work just fine. The OSF API, at the time of
writing, has a limit of 10,000 requests per day. This limit is
account-specific, and if it were exceeded DataPipe would be
unable to store additional files until the following day. OSF
components have a storage limit of 5 GB for private com-
ponents and 50 GB for public components, and a maximum
file size of 5 GB. DataPipe creates a new component for
each experiment, so this limit is experiment-specific when
using DataPipe.
Why is this design better than interacting with the OSF API
directly? The OSF API can be directly accessed by any-
one with an OSF account, so a researcher could send data
directly to the OSF rather than going through DataPipe.
What's the benefit of using DataPipe?
Communication with the OSF API requires authoriza-
tion via a personal access token. The token is a long string
of numbers and letters, and functions like a password to the
OSF account. In order to use the OSF API directly from a
JavaScript experiment, the OSF token would need to be pub-
licly viewable by the participant (since it is the participant's
computer that would be communicating with the OSF). This
would be risky. A malicious participant could view the token
and then make API calls to the OSF as if they were the
researcher.
DataPipe adds a layer of security between the OSF token
and the participant. The researcher using DataPipe provides
DataPipe with the OSF token, and the participant sends data
to DataPipe. The only information that the participant can
access is the ID of the experiment on DataPipe and the OSF
token is securely stored in DataPipe's database.
By routing requests through DataPipe, the researcher
has a lot more control over what actions a participant can
perform on the OSF repository. Tokens on the OSF can be
assigned certain permissions, or actions that can be per-
formed using the token. At the time of writing this article,
the options for permissions are to give a token full read-only
access to all OSF projects in an account, full write access
Behavior Research Methods
to all OSF projects in an account, read access for personal
profile data, and read access for the email address. This
means that, if a researcher were using just the OSF API to
write data, the participant would then be able to have full
write access to all OSF projects in the researcher's account.
This is much less granular access control than DataPipe can
provide. DataPipe will only write data to the single OSF
component that is set in the configuration for an experiment.
How does DataPipe's design make online experiments
free? Setting up a web server to host an experiment is one
of the more technically challenging aspects of configuring an
online experiment. While there are open-source tools avail-
able that make this process much easier (e.g., JATOS and
PsiTurk), most solutions still require some technical skills
and access to a computer that can function as a web server.
The exception to this is a handful of commercial platforms
for research, which greatly reduce the technical challenges
but with the tradeoff of costing money to use.
Hosting an online experiment does not need to be expen-
sive. The (relatively) expensive parts are the storage and
bandwidth required to host the experiment files (e.g., poten-
tially a large number of media files) and the infrastructure for
managing the data (e.g., some kind of permanent database or
file storage). Fortunately, there are platforms that are willing
to provide these services for free. Many web hosting provid-
ers offer free hosting for websites and media files that are
"static", meaning that the files are the same for every user and
there is no communication with a database. (An example of a
non-static site would be a social media page, where the web-
site needs to reference stored information in order to render
the correct content to the user.) Usually, online experiments
are not static because a database is needed to store the data
generated by the experiment. DataPipe solves this problem by
providing a way for a static website to send data to the OSF.
Does this mean that DataPipe is subsidizing the cost? Not
significantly. The main organizations that are incurring a cost
are the hosting provider (e.g., GitHub) and the data storage
provider (OSF). DataPipe serves as a bridge between these
services and, since it does not store any experiment data
directly, is a very low-cost service to run. The cost, based on
cloud computing costs at the time of writing, is about 1 cent
per 500 data files processed. This isn't nothing, and if Data-
Pipe becomes very popular then it may require some fund-
raising to support, but a monthly budget of $100 USD via a
donation model could handle roughly 5 million data files.
Implementation
This section describes, at a high level, how DataPipe is built
and how to communicate with the API. This section is aimed
at researchers who have some technical familiarity with web
applications. Researchers who are interested in simply using
DataPipe can follow the guides on the DataPipe website for
a non-technical overview of how to get started.
There are three major components to DataPipe: (1) The
API, (2) The experiment configuration database, and (3) The
front-end web application (Fig. 1). The DataPipe codebase
is open source. It is available at https://​github.​com/​jspsy​ch/​
datap​ipe.
The API There are currently three API endpoints, one for
each of the features described in the previous section. The
/api/data endpoint is used for saving text-based data, /api/
base64 is used for saving base64-encoded data, and /api/con-
dition is used for sequential condition assignment. The API
uses standard HTTP REST-style requests. Each API function
returns standardized status codes (e.g., 201 on a successful
create request and 400 on an invalid request) and informative
error messages in the case of missing or invalid informa-
tion. An example API request is shown in Code Block 1.
JavaScript-based code samples for all of the API endpoints
are provided in the DataPipe experiment dashboard.
Code Block 1. Example API request using JavaScript's fetch
method to create a CSV file on the OSF. There are three
parameters that are sent in the body of the request. The
experimentID identifies which DataPipe experiment the
data are connected to, and is provided by DataPipe when an
experiment is created. The filename must be a unique identi-
fier. The data are sent as a text string. In this example, it is
assumed that the dataAsString variable contains data that is
already formatted as a CSV — for example, the output from
jsPsych.data.get().csv().
The DataPipe API can be used by any experiment soft-
ware that can make HTTP requests, which includes all online
experiments and most offline experiments. API calls can be
made by Python code (PsychoPy; OpenSesame), MATLAB
code (Psychtoolbox), and most other languages. While Data-
Pipe can be used by offline experiments, it is most useful for
online experiments. When experiments are being conducted
offline it is safe to use the OSF API directly because the OSF
13

access token will not be exposed2. However, some research-
ers may choose to use DataPipe anyways because it simpli-
fies the configuration process.
The DataPipe API is hosted using a set of Google Cloud
Functions. When an experiment makes a request to one of
the DataPipe API endpoints, the function is run on Google
Cloud servers. The computing resources allocated to these
functions automatically scale in response to increased load,
so even in the case of high demand for the DataPipe API
there should be no performance problems. The API can
easily handle hundreds of concurrent requests, and given
that the API functions take only a few seconds to run, it is
unlikely that usage will ever go much beyond this. If it does,
additional resources can be provisioned to cover the usage.
Experiment configuration database The experiment config-
uration database sits in between the web application and the
API. It stores information for each experiment on DataPipe,
including which OSF component each experiment connects
to, which features are enabled for an experiment, and valida-
tion rules. When an API request is made, the cloud function
accesses the database to ensure the request is allowed. The
database does not store any research data.
The database itself, as well as the rest of the backend
features of DataPipe, is implemented using Google's Fire-
base application framework. Firebase includes features for
hosting, account management, and document-based database
storage. The web application and all associated user account
data is hosted on Google Cloud, so DataPipe gets the ben-
efits of Google's infrastructure for managing and securing
a web application.
Front‑end web application The website at https://p​ ipe.j​ spsy​
ch.​org is built using NextJS, Chakra UI, and React. The
website allows users to create and configure experiments,
which results in changes to the experiment configuration
database. In theory, these changes to the database could be
made without interacting with the website. A future version
of DataPipe might therefore support programmatically set-
ting up experiments, e.g., through a command line interface
or through experiment creation software.
jsPsych plugin
To help researchers who are using jsPsych (de Leeuw, 2015;
de Leeuw et al., 2023), there is a jsPsych plugin jsPsych-pipe
that implements all of the standard API calls to DataPipe.
2
JavaScript code, used in all online experiments, can always be
viewed, so it is not too difficult for someone to find the access token
in the code. With offline experiments, the code is not easily viewable
by the research participant and there is little risk to using the OSF
API directly.
13
Behavior Research Methods
The plugin is available in the jsPsych community contribu-
tions repository (https://g​ ithub.c​ om/j​ spsyc​ h/j​ spsyc​ h-c​ ontri​ b/​
tree/​main/​packa​ges/​plugin-​pipe). Using this plugin requires
adding just a few lines of code to a jsPsych experiment,
specifying the DataPipe experiment ID, the filename, and
the data to be saved. The plugin can be inserted onto a time-
line to run at a specific point. This is a convenient way to
save all of the data at the end of an experiment.
There are also static methods in the plugin that can be
called separately from being added to an experiment time-
line. One example use case for the static methods is to save
audio or video recordings. If an experiment records a lot of
media from a user, it may require a lot of browser memory
to store all of the data until the end of the experiment. Trans-
mitting all of the data at once will also cause a longer delay.
A good alternative is to send a request to DataPipe at the
end of a trial that records audio data. The static method of
the pipe plugin can be called in the audio recording trial's
on_finish event. Once the file is on the server, the copy that
is stored in the participant's browser can be deleted.
Risks of using DataPipe
There are some unavoidable risks of using a service that can
automatically write data that is gathered remotely over the
Internet. DataPipe is designed to mitigate these risks, but it
is not risk free. These risks include:
1. The researcher must provide DataPipe with an OSF
token that grants write access to their OSF account. In
the event that DataPipe's database is breached, these
tokens could become public and allow users to make
direct writes (through the OSF API) to a user's account.
Access to such a token would not cause a researcher to
lose access to their OSF account like a leaked password
might, but it would still be a serious security vulner-
ability.
  This risk can be mitigated by a researcher disabling
any unused OSF tokens through the OSF token settings.
A token can be revoked by the researcher through the
OSF at any point. DataPipe's documentation recom-
mends that users disable tokens as soon as data collec-
tion is complete to reduce the risk of malicious use.
2. DataPipe creates an open connection between the Inter-
net and an OSF component. A technically savvy user
could write fake data to the OSF component by making
additional requests to the DataPipe service or modifying
the requests that the experiment generates.
  This type of risk is nearly always present with online
experiments because the data are usually measured and
recorded on the participant's computer before being sent
to the server. A malicious user could change the data in
Behavior Research Methods
between when it is measured and when it is sent to the
server, or could create fake data files and send them to
the server.
  The typical ways to mitigate this risk are to validate
incoming data files and to ensure that any fake data can-
not interfere with legitimate data. DataPipe does both of
these things. First, DataPipe will never overwrite exist-
ing files on the OSF, so a malicious user cannot delete
existing data. If a user sends a request with a filename
that already exists, DataPipe will refuse the request. Sec-
ond, the researcher can specify a set of custom valida-
tion criteria that DataPipe will use to check incoming
data files.
3. Experiments using DataPipe are dependent on DataPipe
being available and functional. If DataPipe is down or
otherwise not working, an experiment cannot collect
data and researchers will be dependent on the DataPipe
team to fix the problem. Furthermore, DataPipe is not a
commercial venture with a dedicated user support team,
so there is some risk that support may be slow.
  Unfortunately, individual researchers have little con-
trol over this risk. However, researchers should still
feel confident using DataPipe. DataPipe is hosted using
the Google Cloud, so it benefits from the robustness
of Google's infrastructure to make sure the service is
secure and keeps running. Second, DataPipe is entirely
open source, so researchers can inspect the codebase to
see exactly how DataPipe works. Third, DataPipe has a
robust set of continuous integration testing, including a
separate testing/staging environment for running a suite
of automated tests on the API. This should reduce the
likelihood of bugs making it into the production service.
  Finally, because DataPipe is open source, a researcher
could also choose to operate their own instance of Data-
Pipe or operate a more limited set of features based on
the DataPipe source code. For example, a researcher
could use just the code that runs the API to launch their
own lab-specific copy. This would eliminate the risk of
being dependent on the DataPipe team and would also
avoid the risk of giving an OSF token to DataPipe.
Privacy
One kind of privacy concern that a researcher might have
about using DataPipe is whether it is possible to collect data
without making the data immediately public on the Inter-
net. Some researchers may want to use DataPipe to collect
data without making their data born-open. Others may want
to make the data born-open but only after a short delay to
ensure no personally identifying information is included
in the data. For example, this could be a concern in an
experiment with open-ended questions that may lead some
participants to reveal information that should not be included
in the open data set.
DataPipe can be used to collect private data. By default,
the OSF component that DataPipe creates to store data in a
project is private, so only members of the OSF project can
access it. Researchers can choose to make this component
public for truly born-open data, or can keep data private
until they are ready to release it. One of the advantages of
DataPipe, in terms of encouraging researchers to adopt born-
open practices, is that even with private data collection the
barrier to going public is only changing the visibility of the
repository.
A second kind of privacy concern is whether DataPipe
itself stores or accesses the data during the transfer to the
OSF. This is an especially relevant concern for researchers
who are cautious about or explicitly forbidden from using
US-based servers due to differences in data privacy regula-
tions in the US and, for example, the EU.
DataPipe does not store any of the data it is sent. When
the API is invoked, the data are processed by the Google
Cloud function (which could include validating the content
of the data or converting the format) and then sent to the
OSF API. Once this function is complete, there is no stored
record of the data. Researchers who need or want to host
their data files on a server located outside the US can set
the server location of their OSF project to a non-US locale.
DataPipe does keep some basic logging information about
the requests generated. Specifically, it tracks the number and
type of requests associated with each DataPipe experiment.
Additionally, Google Cloud functions record a temporary
log of each request made. This log includes the URL of the
site that the request originated from (the experiment URL, in
most use cases), the time of the request, the user agent string,
and the IP address that the request originated from. These
logs are automatically deleted after 30 days.
Conclusions
Born-open data collection makes it easier for researchers to
publish all of their data because it makes the process auto-
matic (Rouder, 2016). The goal of DataPipe is to make born-
open data collection an easy default option for researchers.
Internet-based data collection is one of the main ways that
behavioral science is done, and it is a method where data
management is challenging. DataPipe makes online data col-
lection easy by providing a simple set of API endpoints that
can take data and write it directly to an OSF component. This
removes the need for a researcher to set up or provision their
own backend server, which is one of the most complicated
parts about setting up an online experiment. As an added ben-
efit, servers—and services that provide servers—are one of
the main costs of hosting an online experiment, so DataPipe
13

also makes online experiments much cheaper. By reducing
the cost and complexity of running an online experiment
while simultaneously encouraging users to adopt born-open
data collection, DataPipe may be able to shift the incentives
enough for more researchers to adopt this important practice.
Declarations
Conflict of interest The author declares that he has no conflicts of in-
terest or competing interests.
References
Alsheikh-Ali, A. A., Qureshi, W., Al-Mallah, M. H., & Ioannidis, J.
P. (2011). Public availability of published research data in high-
impact journals. PLoS ONE, 6(9), e24357.
Cousineau, D. (2021). Born-Open Data for jsPsych. https://​doi.​org/​10.​
31234/​osf.​io/​rkhng
de Leeuw, J. R. (2015). jsPsych: A JavaScript library for creating
behavioral experiments in a web browser. Behavior Research
Methods, 47, 1–12.
de Leeuw, J.R., Gilbert, R.A., & Luchterhandt, B. (2023). jsPsych:
Enabling an open-source collaborative ecosystem of behavioral
experiments. Journal of Open Source Software, 8(85), 5351.
https://​joss.​theoj.​org/​papers/​10.​21105/​joss.​05351
Gureckis, T. M., Martin, J., McDonnell, J., Rich, A. S., Markant, D.,
Coenen, A., … Chan, P. (2016). psiTurk: An open-source frame-
work for conducting replicable behavioral experiments online.
Behavior Research Methods, 48, 829–842.
Hardwicke, T. E., Thibault, R. T., Kosie, J. E., Wallach, J. D., Kidwell,
M. C., & Ioannidis, J. P. (2022). Estimating the prevalence of trans-
parency and reproducibility-related research practices in psychology
(2014–2017). Perspectives on Psychological Science, 17(1), 239–251.
Hartshorne, J. K., de Leeuw, J. R., Goodman, N. D., Jennings, M.,
& O’Donnell, T. J. (2019). A thousand studies for the price of
one: Accelerating psychological science with Pushkin. Behavior
Research Methods, 51, 1782–1803.
Hussey, I. (2023). Data is not available upon request. https://​doi.​org/​
10.​31234/​osf.​io/​jbu9r
Kidwell, M. C., Lazarević, L. B., Baranski, E., Hardwicke, T. E.,
Piechowski, S., Falkenberg, L. S., … Nosek, B. A. (2016). Badges
to acknowledge open practices: A simple, low-cost, effective method
for increasing transparency. PLoS Biology, 14(5), e1002456.
Klein, O., Hardwicke, T. E., Aust, F., Breuer, J., Danielsson, H., Hofe-
lich Mohr, A., … Frank, M. C. (2018). A practical guide for trans-
parency in psychological science. Collabra: Psychology, 4(1), 20.
https://​doi.​org/​10.​1525/​colla​bra.​158
13
Behavior Research Methods
Lange, K., Kühn, S., & Filevich, E. (2015). Just Another Tool for
Online Studies (JATOS): An easy solution for setup and manage-
ment of web servers supporting online studies. PLoS ONE, 10(6),
e0130834.
Morey, R. D., Chambers, C. D., Etchells, P. J., Harris, C. R., Hoek-
stra, R., Lakens, D., ... & Zwaan, R. A. (2016). The peer review-
ers’ openness initiative: Incentivizing open research practices
through peer review. Royal Society Open Science, 3(1), 150547.
https://doi.org/10.1098/rsos.150547
Murray-Rust, P. (2008). Open data in science. Nature Precedings.
https://​doi.​org/​10.​1038/​npre.​2008.​1526.1
National Institutes of Health. (2020). Final NIH policy for data man-
agement and sharing (NIH Identifier NOT-OD-21-013). U.S.
Department of Health and Human Services, National Institutes
of Health. Available from https://​grants.​nih.​gov/​grants/​guide/​
notice-​files/​NOT-​OD-​21-​013.​html
Nosek, B. A., Alter, G., Banks, G. C., Borsboom, D., Bowman, S.
D., Breckler, S. J., ... & Yarkoni, T. (2015). Promoting an open
research culture. Science, 348(6242), 1422–1425. https://​doi.​org/​
10.​1126/​scien​ce.​aab23​74
Obels, P., Lakens, D., Coles, N. A., Gottfried, J., & Green, S. A. (2020).
Analysis of open data and computational reproducibility in regis-
tered reports in psychology. Advances in Methods and Practices
in Psychological Science, 3(2), 229–237.
Rouder, J. N. (2016). The what, why, and how of born-open data.
Behavior Research Methods, 48, 1062–1069.
Van der Eynden, V., Corti, L., Woollard, M., Bishop, L., & Horton, L.
(2011). Managing and sharing data—best practices for research-
ers. University of Essex.
Vanpaemel, W., Vermorgen, M., Deriemaecker, L., & Storms, G.
(2015). Are we wasting a good crisis? The availability of psycho-
logical research data after the storm. Collabra, 1(1). https://​doi.​
org/​10.​1525/​colla​bra.​13
Zorowitz, S., & Bennett, D. (2022). NivTurk (v1.2-prolific). Zenodo.
https://​doi.​org/​10.​5281/​zenodo.​66092​18
Zuiderwijk, A., Shinde, R., & Jeng, W. (2020). What drives and inhibits
researchers to share and use open research data? A systematic
literature review to analyze factors influencing open research data
adoption. PLoS One, 15(9), e0239283. https://​doi.​org/​10.​1371/​
journ​al.​pone.​02392​83
Publisher's note Springer Nature remains neutral with regard to
jurisdictional claims in published maps and institutional affiliations.
Open practices statement DataPipe is open source. The code is
available at https://​github.​com/​jspsy​ch/​datap​ipe
Springer Nature or its licensor (e.g. a society or other partner) holds
exclusive rights to this article under a publishing agreement with the
author(s) or other rightsholder(s); author self-archiving of the accepted
manuscript version of this article is solely governed by the terms of
such publishing agreement and applicable law.