CINXE.COM

<!DOCTYPE html> <html lang="en" itemscope itemtype="http://schema.org/WebPage"> <head> <meta charset="utf-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0"> <title>The Principles of Open Scholarly Infrastructure</title> <meta name="description" content="POSI Version 1.1 Released November 2023 The POSI Adopters—15 organisations at the time—worked on clarifications to the original principles to create version 1.1 on 3rd November 2023. The new/always-current version is below. See the marked-up changes with explanations and the archive of the original version 1.0, for reference. Governance Coverage across the scholarly enterprise – research transcends disciplines, geography, institutions, and stakeholders. Organisations and the infrastructure they run need to reflect this. Stakeholder Governed – a board-governed organisation drawn from the stakeholder community builds confidence that the organisation will take decisions driven by community consensus and a balance of interests. Non-discriminatory participation or membership – we see the best option as an “opt-in” approach with principles of non-discrimination and inclusivity where any stakeholder group may express an interest and should be welcome. Representation in governance must reflect the character of the community or membership. Transparent governance – to achieve trust, the processes and policies for selecting representatives to governance groups should be transparent (within the constraints of privacy laws). Cannot lobby – infrastructure organisations should not lobby for regulatory change to cement their own positions or narrow self-interest. However, an infrastructure organisation’s role is to support its community, and this can include advocating for policy changes. Living will – a powerful way to create trust is to publicly describe a plan addressing the conditions under which an organisation or service would be wound down. It should include how this would happen and how any assets could be archived and preserved when passed to a successor organisation or service. Any such organisation or service must adopt POSI and honour the POSI principles. Formal incentives to fulfil mission & wind-down – infrastructures exist for a specific purpose, and that purpose can be radically simplified or even rendered unnecessary by technological or social change. Organisations and services should regularly review community support and the need for their activities. If it is possible, the organisation or service (and staff) should have direct incentives to deliver on the mission and wind down. Sustainability Time-limited funds are used only for time-limited activities – operations are supported by sustainable revenue sources - whereas time-limited funds are used only for time-limited activities. Depending on grants to fund ongoing and/or long-term infrastructure operations fully makes them fragile and distracts from building core infrastructure. Goal to generate surplus – organisations (or services) that define sustainability based merely on recovering costs are brittle and stagnant. It is not enough to merely survive; organisations and services have to be able to adapt and change. To weather economic, social and technological volatility, they need financial resources beyond immediate operating costs. Goal to create financial reserves – a high priority should be having ring-fenced financial reserves, separate from operating funds, that can support implementing living will plans, including a complete, orderly wind down or transition to a successor organisation, or major unexpected events. Mission-consistent revenue generation – revenue sources should be evaluated against the infrastructure’s mission and not run counter to the aims of the organisation or service. Revenue based on services, not data – data related to the running of the scholarly infrastructure should be community property. Appropriate revenue sources might include value-added services, consulting, API Service Level Agreements or membership fees. Insurance Open source – all software and assets required to run the infrastructure should be available under an open-source licence. This does not include other software that may be involved with running the organisation. Open data (within constraints of privacy laws) – For an infrastructure to be forked (reproduced), it will be necessary to replicate all relevant data. The CC0 waiver is the best practice in making data openly and legally available. Privacy and data protection laws will limit the extent to which this is possible. Available data (within constraints of privacy laws) – it is not enough that the data be “open” if there is no practical way to obtain it. Underlying data should be made easily available via periodic open data dumps. Patent non-assertion – the organisation should commit to a patent non-assertion policy or covenant. The organisation may obtain patents to protect its own operations but not use them to prevent the community from replicating the infrastructure. Cite as Bilder G, Lin J, Neylon C (2020), The Principles of Open Scholarly Infrastructure, retrieved [date], [https://doi.org/10.24343/C34W2H](https://doi.org/10.24343/C34W2H)"><script type="application/ld+json"> { "@context": "http://schema.org", "@type": "WebSite", "name": "The Principles of Open Scholarly Infrastructure", "url": "https:\/\/openscholarlyinfrastructure.org\/" } </script><script type="application/ld+json"> { "@context": "http://schema.org", "@type": "Organization", "name": "", "url": "https:\/\/openscholarlyinfrastructure.org\/" } </script> <meta property="og:title" content="The Principles of Open Scholarly Infrastructure (v1.1, 2023)" /> <meta property="og:description" content="POSI Version 1.1 Released November 2023 The POSI Adopters—15 organisations at the time—worked on clarifications to the original principles to create version 1.1 on 3rd November 2023. The new/always-current version is below. See the marked-up changes with explanations and the archive of the original version 1.0, for reference. Governance Coverage across the scholarly enterprise – research transcends disciplines, geography, institutions, and stakeholders. Organisations and the infrastructure they run need to reflect this. Stakeholder Governed – a board-governed organisation drawn from the stakeholder community builds confidence that the organisation will take decisions driven by community consensus and a balance of interests. Non-discriminatory participation or membership – we see the best option as an “opt-in” approach with principles of non-discrimination and inclusivity where any stakeholder group may express an interest and should be welcome. Representation in governance must reflect the character of the community or membership. Transparent governance – to achieve trust, the processes and policies for selecting representatives to governance groups should be transparent (within the constraints of privacy laws). Cannot lobby – infrastructure organisations should not lobby for regulatory change to cement their own positions or narrow self-interest. However, an infrastructure organisation’s role is to support its community, and this can include advocating for policy changes. Living will – a powerful way to create trust is to publicly describe a plan addressing the conditions under which an organisation or service would be wound down. It should include how this would happen and how any assets could be archived and preserved when passed to a successor organisation or service. Any such organisation or service must adopt POSI and honour the POSI principles. Formal incentives to fulfil mission & wind-down – infrastructures exist for a specific purpose, and that purpose can be radically simplified or even rendered unnecessary by technological or social change. Organisations and services should regularly review community support and the need for their activities. If it is possible, the organisation or service (and staff) should have direct incentives to deliver on the mission and wind down. Sustainability Time-limited funds are used only for time-limited activities – operations are supported by sustainable revenue sources - whereas time-limited funds are used only for time-limited activities. Depending on grants to fund ongoing and/or long-term infrastructure operations fully makes them fragile and distracts from building core infrastructure. Goal to generate surplus – organisations (or services) that define sustainability based merely on recovering costs are brittle and stagnant. It is not enough to merely survive; organisations and services have to be able to adapt and change. To weather economic, social and technological volatility, they need financial resources beyond immediate operating costs. Goal to create financial reserves – a high priority should be having ring-fenced financial reserves, separate from operating funds, that can support implementing living will plans, including a complete, orderly wind down or transition to a successor organisation, or major unexpected events. Mission-consistent revenue generation – revenue sources should be evaluated against the infrastructure’s mission and not run counter to the aims of the organisation or service. Revenue based on services, not data – data related to the running of the scholarly infrastructure should be community property. Appropriate revenue sources might include value-added services, consulting, API Service Level Agreements or membership fees. Insurance Open source – all software and assets required to run the infrastructure should be available under an open-source licence. This does not include other software that may be involved with running the organisation. Open data (within constraints of privacy laws) – For an infrastructure to be forked (reproduced), it will be necessary to replicate all relevant data. The CC0 waiver is the best practice in making data openly and legally available. Privacy and data protection laws will limit the extent to which this is possible. Available data (within constraints of privacy laws) – it is not enough that the data be “open” if there is no practical way to obtain it. Underlying data should be made easily available via periodic open data dumps. Patent non-assertion – the organisation should commit to a patent non-assertion policy or covenant. The organisation may obtain patents to protect its own operations but not use them to prevent the community from replicating the infrastructure. Cite as Bilder G, Lin J, Neylon C (2020), The Principles of Open Scholarly Infrastructure, retrieved [date], [https://doi.org/10.24343/C34W2H](https://doi.org/10.24343/C34W2H)"> <meta property="og:image" content="https://openscholarlyinfrastructure.org/img/avatar-icon.png" /> <meta property="og:url" content="https://openscholarlyinfrastructure.org/" /> <meta property="og:type" content="website" /> <meta property="og:site_name" content="The Principles of Open Scholarly Infrastructure" /> <meta name="twitter:title" content="The Principles of Open Scholarly Infrastructure (v1.1, 2023)" /> <meta name="twitter:description" content="POSI Version 1.1 Released November 2023 The POSI Adopters—15 organisations at the time—worked on clarifications to the original principles to create version 1.1 on 3rd November 2023. The …"> <meta name="twitter:image" content="https://openscholarlyinfrastructure.org/img/avatar-icon.png" /> <meta name="twitter:card" content="summary_large_image" /> <link href='https://openscholarlyinfrastructure.org/img/favicon.ico' rel='icon' type='image/x-icon'/> <meta name="generator" content="Hugo 0.136.4"> <link rel="alternate" href="https://openscholarlyinfrastructure.org/index.xml" type="application/rss+xml" title="The Principles of Open Scholarly Infrastructure"><link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/katex@0.16.7/dist/katex.min.css" integrity="sha384-3UiQGuEI4TTMaFmGIZumfRPtfKQ3trwQE2JgosJxCnGmQpL/lJdjpcHkaaFwHlcI" crossorigin="anonymous"> <link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.5.0/css/all.css" integrity="sha384-B4dIYHKNBt8Bc12p+WXckhzcICo0wtJAoU8YZTY5qE0Id1GSseTk6S+L3BlXeVIU" crossorigin="anonymous"> <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/bootstrap@3.4.1/dist/css/bootstrap.min.css" integrity="sha384-HSMxcRTRxnN+Bdg0JdbxYKrThecOKuH5zCYotlSAcp1+c8xmyTe9GYg1l9a69psu" crossorigin="anonymous"><link rel="stylesheet" href="https://openscholarlyinfrastructure.org/css/main.css" /><link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Lora:400,700,400italic,700italic" /> <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Open+Sans:300italic,400italic,600italic,700italic,800italic,400,300,600,700,800" /><link rel="stylesheet" href="https://openscholarlyinfrastructure.org/css/syntax.css" /><link rel="stylesheet" href="https://openscholarlyinfrastructure.org/css/codeblock.css" /><link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/photoswipe/4.1.2/photoswipe.min.css" integrity="sha384-h/L2W9KefUClHWaty3SLE5F/qvc4djlyR4qY3NUV5HGQBBW7stbcfff1+I/vmsHh" crossorigin="anonymous"> <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/photoswipe/4.1.2/default-skin/default-skin.min.css" integrity="sha384-iD0dNku6PYSIQLyfTOpB06F2KCZJAKLOThS5HRe8b3ibhdEQ6eKsFf/EeFxdOt5R" crossorigin="anonymous"> </head> <body> <nav class="navbar navbar-default navbar-fixed-top navbar-custom"> <div class="container-fluid"> <div class="navbar-header"> <button type="button" class="navbar-toggle" data-toggle="collapse" data-target="#main-navbar"> <span class="sr-only">Toggle navigation</span> <span class="icon-bar"></span> <span class="icon-bar"></span> <span class="icon-bar"></span> </button> <a class="navbar-brand" href="https://openscholarlyinfrastructure.org/">The Principles of Open Scholarly Infrastructure</a> </div> <div class="collapse navbar-collapse" id="main-navbar"> <ul class="nav navbar-nav navbar-right"> <li> <a title="About" href="https://openscholarlyinfrastructure.org/about/">About</a> </li> <li> <a title="Posse" href="https://openscholarlyinfrastructure.org/posse/">Posse</a> </li> <li> <a title="FAQ" href="https://openscholarlyinfrastructure.org/faq/">FAQ</a> </li> <li> <a title="Discussion" href="https://openscholarlyinfrastructure.org/discussion/">Discussion</a> </li> </ul> </div> <div class="avatar-container"> <div class="avatar-img-border"> <a title="The Principles of Open Scholarly Infrastructure" href="https://openscholarlyinfrastructure.org/"> <img class="avatar-img" src="https://openscholarlyinfrastructure.org/img/avatar-icon.png" alt="The Principles of Open Scholarly Infrastructure" /> </a> </div> </div> </div> </nav> <div class="pswp" tabindex="-1" role="dialog" aria-hidden="true"> <div class="pswp__bg"></div> <div class="pswp__scroll-wrap"> <div class="pswp__container"> <div class="pswp__item"></div> <div class="pswp__item"></div> <div class="pswp__item"></div> </div> <div class="pswp__ui pswp__ui--hidden"> <div class="pswp__top-bar"> <div class="pswp__counter"></div> <button class="pswp__button pswp__button--close" title="Close (Esc)"></button> <button class="pswp__button pswp__button--share" title="Share"></button> <button class="pswp__button pswp__button--fs" title="Toggle fullscreen"></button> <button class="pswp__button pswp__button--zoom" title="Zoom in/out"></button> <div class="pswp__preloader"> <div class="pswp__preloader__icn"> <div class="pswp__preloader__cut"> <div class="pswp__preloader__donut"></div> </div> </div> </div> </div> <div class="pswp__share-modal pswp__share-modal--hidden pswp__single-tap"> <div class="pswp__share-tooltip"></div> </div> <button class="pswp__button pswp__button--arrow--left" title="Previous (arrow left)"> </button> <button class="pswp__button pswp__button--arrow--right" title="Next (arrow right)"> </button> <div class="pswp__caption"> <div class="pswp__caption__center"></div> </div> </div> </div> </div> <header class="header-section "> <div class="intro-header no-img"> <div class="container"> <div class="row"> <div class="col-lg-8 col-lg-offset-2 col-md-10 col-md-offset-1"> <div class="page-heading"> <h1>The Principles of Open Scholarly Infrastructure</h1> <hr class="small"> </div> </div> </div> </div> </div> </header> <div role="main" class="container"> <div class="row"> <div class="col-lg-8 col-lg-offset-2 col-md-10 col-md-offset-1"> <div class="xwell"> <p><strong><em>POSI Version 1.1 Released November 2023</em></strong> <br> <em>The POSI <a href="https://openscholarlyinfrastructure.org/posse">Adopters</a>—15 organisations at the time—worked on clarifications to the original principles to create version 1.1 on 3rd November 2023. The new/always-current version is below. See the <a href="https://openscholarlyinfrastructure.org/posi-v1.1-revisions.pdf">marked-up changes with explanations</a> and the archive of the <a href="https://openscholarlyinfrastructure.org/posi-v1.0">original version 1.0</a>, for reference.</em>  </p> <div class="well"> <h2 id="governance">Governance</h2> <ul> <li><strong>Coverage across the scholarly enterprise</strong> – research transcends disciplines, geography, institutions, and stakeholders. Organisations and the infrastructure they run need to reflect this.</li> <li><strong>Stakeholder Governed</strong> – a board-governed organisation drawn from the stakeholder community builds confidence that the organisation will take decisions driven by community consensus and a balance of interests.</li> <li><strong>Non-discriminatory participation or membership</strong> – we see the best option as an “opt-in” approach with principles of non-discrimination and inclusivity where any stakeholder group may express an interest and should be welcome. Representation in governance must reflect the character of the community or membership.</li> <li><strong>Transparent governance</strong> – to achieve trust, the processes and policies for selecting representatives to governance groups should be transparent (within the constraints of privacy laws).</li> <li><strong>Cannot lobby</strong> – infrastructure organisations should not lobby for regulatory change to cement their own positions or narrow self-interest. However, an infrastructure organisation’s role is to support its community, and this can include advocating for policy changes.</li> <li><strong>Living will</strong> – a powerful way to create trust is to publicly describe a plan addressing the conditions under which an organisation or service would be wound down. It should include how this would happen and how any assets could be archived and preserved when passed to a successor organisation or service. Any such organisation or service must adopt POSI and honour the POSI principles.</li> <li><strong>Formal incentives to fulfil mission & wind-down</strong> – infrastructures exist for a specific purpose, and that purpose can be radically simplified or even rendered unnecessary by technological or social change. Organisations and services should regularly review community support and the need for their activities. If it is possible, the organisation or service (and staff) should have direct incentives to deliver on the mission and wind down.</li> </ul> <h2 id="sustainability">Sustainability</h2> <ul> <li><strong>Time-limited funds are used only for time-limited activities</strong> – operations are supported by sustainable revenue sources - whereas time-limited funds are used only for time-limited activities. Depending on grants to fund ongoing and/or long-term infrastructure operations fully makes them fragile and distracts from building core infrastructure.</li> <li><strong>Goal to generate surplus</strong> – organisations (or services) that define sustainability based merely on recovering costs are brittle and stagnant. It is not enough to merely survive; organisations and services have to be able to adapt and change. To weather economic, social and technological volatility, they need financial resources beyond immediate operating costs.</li> <li><strong>Goal to create financial reserves</strong> – a high priority should be having ring-fenced financial reserves, separate from operating funds, that can support implementing living will plans, including a complete, orderly wind down or transition to a successor organisation, or major unexpected events.</li> <li><strong>Mission-consistent revenue generation</strong> – revenue sources should be evaluated against the infrastructure’s mission and not run counter to the aims of the organisation or service.</li> <li><strong>Revenue based on services, not data</strong> – data related to the running of the scholarly infrastructure should be community property. Appropriate revenue sources might include value-added services, consulting, API Service Level Agreements or membership fees.</li> </ul> <h2 id="insurance">Insurance</h2> <ul> <li><strong>Open source</strong> – all software and assets required to run the infrastructure should be available under an open-source licence. This does not include other software that may be involved with running the organisation.</li> <li><strong>Open data (within constraints of privacy laws)</strong> – For an infrastructure to be forked (reproduced), it will be necessary to replicate all relevant data. The <a href="https://creativecommons.org/publicdomain/zero/1.0">CC0 waiver</a> is the best practice in making data openly and legally available. Privacy and data protection laws will limit the extent to which this is possible.</li> <li><strong>Available data (within constraints of privacy laws)</strong> – it is not enough that the data be “open” if there is no practical way to obtain it. Underlying data should be made easily available via periodic open data dumps.</li> <li><strong>Patent non-assertion</strong> – the organisation should commit to a patent non-assertion policy or covenant. The organisation may obtain patents to protect its own operations but not use them to prevent the community from replicating the infrastructure.</li> </ul> </div>  <p><em>Cite as <code>Bilder G, Lin J, Neylon C (2020), The Principles of Open Scholarly Infrastructure, retrieved [date], [https://doi.org/10.24343/C34W2H](https://doi.org/10.24343/C34W2H)</code></em></p> </div> <div class="posts-list"> </div> </div> </div> </div> <div class="page-meta"> (Last modified on November 10, 101010) </div> <footer> <div class="container"> <div class="row"> <div class="col-lg-8 col-lg-offset-2 col-md-10 col-md-offset-1"> <ul class="list-inline text-center footer-links"> <li> <a href="https://openscholarlyinfrastructure.org/index.xml" title="RSS"> <span class="fa-stack fa-lg"> <i class="fas fa-circle fa-stack-2x"></i> <i class="fas fa-rss fa-stack-1x fa-inverse"></i> </span> </a> </li> </ul> <p class="credits copyright text-muted">  • © 2024  •  <a href="https://openscholarlyinfrastructure.org/">The Principles of Open Scholarly Infrastructure</a> </p> <p class="credits theme-by text-muted"> <a href="https://gohugo.io">Hugo v0.136.4</a> powered  •  Theme <a href="https://github.com/halogenica/beautifulhugo">Beautiful Hugo</a> adapted from <a href="https://deanattali.com/beautiful-jekyll/">Beautiful Jekyll</a>  • [<a href="false9c3e32d10f0c15683b05dc9512db27e8b103b82e">9c3e32d1</a>] </p> </div> </div> </div> </footer><script defer src="https://cdn.jsdelivr.net/npm/katex@0.16.7/dist/katex.min.js" integrity="sha384-G0zcxDFp5LWZtDuRMnBkk3EphCK1lhEf4UEyEM693ka574TZGwo4IWwS6QLzM/2t" crossorigin="anonymous"></script> <script defer src="https://cdn.jsdelivr.net/npm/katex@0.16.7/dist/contrib/auto-render.min.js" integrity="sha384-+VBxd3r6XgURycqtZ117nYw44OOcIax56Z4dCRWbxyPt0Koah1uHoK0o4+/RRE05" crossorigin="anonymous" onload="renderMathInElement(document.body);"></script> <script src="https://code.jquery.com/jquery-3.7.0.slim.min.js" integrity="sha384-w5y/xIeYixWvfM+A1cEbmHPURnvyqmVg5eVENruEdDjcyRLUSNej7512JQGspFUr" crossorigin="anonymous"></script> <script src="https://cdn.jsdelivr.net/npm/bootstrap@3.4.1/dist/js/bootstrap.min.js" integrity="sha384-aJ21OjlMXNL5UyIl/XNwTMqvzeRMZH2w8c5cRVpzpU8Y5bApTppSuUkhZXN0VxHd" crossorigin="anonymous"></script> <script src="https://openscholarlyinfrastructure.org/js/main.js"></script><script src="https://cdnjs.cloudflare.com/ajax/libs/photoswipe/4.1.2/photoswipe.min.js" integrity="sha384-QELNnmcmU8IR9ZAykt67vGr9/rZJdHbiWi64V88fCPaOohUlHCqUD/unNN0BXSqy" crossorigin="anonymous"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/photoswipe/4.1.2/photoswipe-ui-default.min.js" integrity="sha384-m67o7SkQ1ALzKZIFh4CiTA8tmadaujiTa9Vu+nqPSwDOqHrDmxLezTdFln8077+q" crossorigin="anonymous"></script><script src="https://openscholarlyinfrastructure.org/js/load-photoswipe.js"></script> </body> </html>