Frequently Asked Questions

The OA Switchboard initiative is a global, not-for-profit collaboration between funders, institutions and publishers to provide essential infrastructure, standards and back office services to facilitate the fulfilment of open access strategies across business models, policies and agreements. The goal is to achieve a breakthrough in the transformation of the market such that Open Access is supported as the predominant model of publication.

Throughout 2020, a project (overseen by OASPA, funded through a sponsorship model) was run to prepare for the OA Switchboard to go live as an operational solution. Following a successful project, as of January 2021, the OA Switchboard moved to an operational stage with a sustainable governance structure and funding model.

​

Read more here.

The reasons we choose open source:

• By design: open source software licenses promote collaboration and sharing.

• By mechanism: open source is an essential mechanism for building transparency and (therefore) trust. Open source ensures that all parties can validate that there are neutral and ‘accurate’ assessment algorithms, providing a guarantee that the OA Switchboard can be validated as the neutral host and facilitator it aspires to be.

• No vendor lock-in, guaranteed exit scenario.

• Cost: free license model.

• It brings future security because others can build on our work.

The following software is developed for us by our tech partner, and delivered to us under and Open Source license (MIT):

• Core (message hub & data store): Open source code, fully transparent. The (public) repository and documentation can be found here: https://bitbucket.org/oaswitchboard/api/

• Web application (with User Interface): developed and released as part of the Open Source Pubsweet framework. Possibility to contribute via community owned/shared/joint development

The following parts are developed for us by our tech partner, and delivered to us under an Open Source license (MIT). Contributions made available to the community for use and further development:

• Connectors: Open source code and (where possible) part of an Open Source project like OJS (plugin), etc. The possibility to contribute via community owned/shared/joint development. Connectors are here: https://bitbucket.org/oaswitchboard/api/src/master/connectors

• Message structure standard: an explanation of the data fields in the message structure can be found here: https://bitbucket.org/oaswitchboard/api/src/master/messages

All source code produced by our tech partner for us, is delivered to Stichting OA Switchboard under an Open Source license. To run it, there is a dependency on AWS Platform-as-a-Service:

• Platform-as-a-Service offered by AWS (Amazon Web Services) is not open source (e.g. API gateway, VPC, server environments, Lambda serverless runtime, messaging services including SQS/SNS/SES)

• Database-as-a-Service offered by AWS is open source, PostgreSQL enabled as a managed database service

The core message hub is highly scalable, especially due to the use of AWS (Amazon Web Services) micro services. AWS is by far the largest cloud provider (hosting almost all large sites in the world), and is scalable and secure. That is exactly the reason why we decided (in coordination with our Tech Advisors and Steering Committee) to not develop this piece ourselves. The above visual shows the message lifecycle for sending a message through the OA Switchboard. The AWS API gateway is linked to a serverless – Lambda validation function that invokes an SQS queue. This is what AWS says about this:

• By default, SQS support up to 300 messages per second.

• Lambda functions with an Amazon SQS trigger can scale up 60 additional instances per minute to a maximum of 1,000 concurrent invocations.

That is over 1 million messages per hour. And that is the default. If more volume and guarantees are required then an SLA is available, however we don’t expect to need it.

Right from the start in the MVP we’ve ensured security and privacy in the OA Switchboard:

• One user (one account) per participant. Authorisation is required, always.

• The Sandbox is for testing purposes. The PRODuction will be made available later.

• We store message header (all) and message body (optional).

• If a participant integrates directly onto the API AND stores their own messages, there is no need to store them at OA Switchboard. *)

• If a participant uses the User Interface OR does not store their own messages, the OA Switchboard will store them. *)

• Only participants sending & receiving a message can retrieve the message body. OA Switchboard staff cannot access a participant’s message body. Unauthorized access is logged.

*) Note that if stakeholder 1 sends a message to stakeholder 2, and for stakeholder 1 point 4 is applicable, and for stakeholder 2 point 5 is applicable, the messages sent by stakeholder 1 are stored in the OA Switchboard.

All participants in OA Switchboard sign the same Service Agreement, with General Terms & Conditions. Relevant clauses:

​

4.1 Wherever legally required under Applicable Data Protection Laws, Participant will obtain any necessary permissions and consents from individuals, to disclose their personal information.

​

4.4 In consideration of Participant receiving Message Content from other Clients and Reports, Participant shall respect all applicable agreements between Participant and other Clients relevant to the Message Content, including but not limited to arrangements regarding confidential information and commercial terms, and Participant shall comply with Applicable Data Protection Laws.

​

5.5 OAS does not have and does not claim to have any ownership of or legal interest in Message Content and Reports, and OAS shall not use Message Content and Reports for any other purpose than delivering the Services to Clients. OAS explicitly declares to not store Message Content or Reports for the purpose of creating a database or derivative products...

​

7. Neither Party may assign, novate or sub-contract any or all of its rights under the Service Agreement without the prior written consent of the other Party.

​

If  a funder/institution works with a vendor for a workflow support solution, we add an annex to the OA Switchboard Service Agreement, to be signed by funder/institution, their vendor and OA Switchboard.

​

Annex #: Assignment/subcontracting

In addition to Clause 7:

1.       Participant chooses to work with <name & full address>, incorporated in <country> under company number <number> (“name”), and wishes to subcontract any or all of its rights under this Agreement to <name>, and OAS hereby approves this. Participant remains liable to OAS under this Agreement for all Responsibilities of Participant (clause 4), despite any subcontracting, and ensures <name> is fully informed and has legally accepted responsibility for this.

2.       <name> is not allowed to use Messages, Message Content or Reports sent by or delivered to Participant for any other purpose than specified by Participant or for the benefit of any entity other than the Participant, as described under this Agreement.

3.       Any breach of this Agreement by <name> will be regarded as a breach by Participant, and may lead to termination of the Agreement.

Annex # to be signed by <name>: ...

A ‘certified integrator’ is a party that, on behalf of a primary stakeholder (a funder, an institution, or a publisher) integrates with the OA Switchboard API in the standard message structure. A party can request to be awarded the ‘certificate’, after which a formal assessment and check will be done, and a decision taken.

The certification process is described in our Code, and includes:

• the integration is operational for minimal 2 institutions and/or 2 funders and/or 2 publishers

• the integration is operational for minimal 2 month, with sufficient volume

• all direct stakeholders in (Stichting) OA Switchboard satisfied

​

Certified integrators, when approved, will be listed on the OA Switchboard website (here) with a summary of the specific integration for each case.

Funders, institutions and publishers with a contract.

No. However, a screening (led by OASPA), to ensure we preserve the integrity of scholarship, will be part of the process.

​

The screening process involves elements of the OASPA membership application process, however if a publisher does not yet meet all of the OASPA criteria it will not necessarily mean exclusion from becoming an OA Switchboard customer and obtaining an account. Reasons for failing the screening for the OA Switchboard could be related to concerns about editorial process, and publishing ethics or behaviour. Ultimately, it is an OASPA decision, and the reasons in case of rejection will be clearly communicated to the party concerned only.

To secure privacy and security. See questions above.

Please see here.

Please check here.