grantapplication.Rmd 37 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421
  1. ---
  2. title: "Open!Make: Towards open and FAIR hardware"
  3. subtitle: "24 months project starting in 04/2021"
  4. 06/2021author:
  5. - name: Prof. Dr.-Ing. Roland Jochem
  6. email: roland.jochem@tu-berlin.de
  7. address1: Chair of Quality Science, Institute for Machine Tools
  8. address2: and Factory Management, Technische Universität Berlin (TUB)
  9. phone: +49 30 314 22005.
  10. - name: Prof. Matthew Larkum
  11. email: matthew.larkum@hu-berlin.de
  12. address2: Institute of Biology, Humboldt-Universität zu Berlin (HUB).
  13. phone: +49 30 450 539 152.
  14. - name: Prof. Tim Landgraf
  15. email: tim.landgraf@fu-berlin.de
  16. address1: Dahlem Center for Machine Learning and Robotics,
  17. address2: Institute of Computer Science, Freie Universität Berlin (FUB)
  18. phone: +49 30 838 75114.
  19. papersize: a4
  20. linestretch: 1.2
  21. fontsize: 12pt
  22. links-as-notes: true
  23. bibliography: "references.bib"
  24. output:
  25. pdf_document:
  26. template: my-template.tex
  27. latex_engine: xelatex
  28. keep_tex: true
  29. mainfont: Times New Roman
  30. ---
  31. ```{r, echo =FALSE}
  32. library(knitcitations)
  33. cleanbib()
  34. cite_options(
  35. citation_format = "pandoc",
  36. style = "markdown",
  37. hyperlink = "to.bib",
  38. cite.style = "authoryear",
  39. super = FALSE,
  40. max.names = 2,
  41. longnamesfirst = FALSE,
  42. check.entries = FALSE
  43. )
  44. ```
  45. ```{r, echo=FALSE, tidy = TRUE}
  46. # authors in the yaml above
  47. #Note for authors: add citation by indicating the doi or directly
  48. # `r citep("doi")` of the paper, I will use knitcitation() to get them in the pdf.
  49. # use only the doi, not the https address
  50. ```
  51. | ![summary figure](https://github.com/open-science-promoters/BUAgrant_OSH/raw/main/visualabstract_buacall.png){width=80%} |
  52. |---|
  53. |Visual abstract. In order to build the foundation for a recognition of hardware making skills in academia, three groups from three Berlin universities will collaborate and create a hardware publication platform, a guide for best practice in collaborative and transparent hardware development, and publish specific hardware using these tools. We will base our work on one side on existing tools, practices and recommendation coming for open science practices, FAIR data principles and software citation, and on the other side on recent development in open hardware evaluation tools. Discussion and collaboration with the gathering of open science hardware and open source hardware association communities will be fostered along the project. We will also promote a discussion on hardware publication and citation inside the FORCE11 networks.|
  54. # Abstract
  55. <!--- of project proposal (Maximum 2000 characters including spaces) --->
  56. Open access publishing, open data and free and open source software have become important pillars of responsible research and innovation (RRI), maximizing the integrity and impact of research outputs. Presently, a new school of thought is emerging which aims to establish an open source hardware (OH) strategy for academia. The importance of OH for society has been well demonstrated during the COVID-19 crisis, when hardware makers started to deliver 3d-printed face shields to medical professionals.
  57. OH communities are extending the principles of free and open source from software development into physical products, enabling hardware reuse and quality control. It also fill a gap in the promotion of FAIR data principles by national funding agencies and the European Commission (seeking to make data findable, accessible, interoperable and reusable).
  58. This project will contribute to this mission through new methods, tools, guidance, standards and awareness building to evaluate and preserve the replicability of hardware in academia. We will pool expertise in hardware evaluation at the TUB, academic hardware making at the FUB and scholarly communication and data management at the HUB. Created solutions will be designed according to our analysis of the community practices (WP1), prototyped and verified (WP2) within ongoing hardware projects of the partners in the fields of automation, physical metrology and virtual reality applications. Lessons learned during the project will feed open education resources we will co-create with the GOSH community (WP3).
  59. Our cross-disciplinary and practice-oriented approach will make the Berlin University Alliance a center of competence for the development of novel standards and tools for hardware documentation and publication.
  60. Open, FAIR hardware presents an opportunity for new carrier paths, and an alternative to traditional intellectual property rights (IPR) practices, reflecting the wider role of academic research in society.
  61. \newpage
  62. # Research content
  63. <!--- Beschreibung der Forschungsinhalte und weitere Erläuterungen
  64. --->
  65. ## Summary and links to call topic
  66. <!---
  67. Kurzbeschreibung des Vorhabens unter Zuordnung zu einem in der Ausschreibung genannten Themenfeld, Darstellung der zentralen Fragestellung bzw. des Projektziels (maximal drei Seiten bzw. 11,000 Zeichen inkl. Leerzeichen)
  68. --->
  69. ### Hardware is absent of scholarly commons
  70. <!---
  71. - Hardware in academia (TL)
  72. - role of hardware in academia
  73. - hardware dissemination
  74. - a career in (open source) hardware
  75. - existing communities
  76. - non-traditional research output publication (JC)
  77. - data and FAIR principles (relation to open data and open source hardware)
  78. - software and software citation group
  79. - contributor lists and CREDIT
  80. - RRID use for reagents and hardware
  81. - Hardware documentation and open next (RM)
  82. - DIN
  83. - wiki review system
  84. --->
  85. Experimental science is typically dependent on hardware: equipment, sensors and machines. One single researcher is often responsible for building, testing and using these solutions, and there is no organized quality control in most labs.
  86. This impediment of information sharing and quality control leads to duplicated work, sometimes inaccuracies in research results, and difficulties in results comparisons, even at a single lab level. Because researchers are lacking guidance on making hardware documentation, the cost for sharing and controlling hardware is too high for them, especially as there is no visible benefit, and they rapidly get stuck in their will of sharing.
  87. Open source hardware describes tangible products “for which a free right of any use belongs to the general public and whose documentation is completely available and freely accessible on the Internet” (DIN SPEC 3105-1:2020 - Open Source Hardware).
  88. It means sharing designs for equipment that anyone can reuse, replicate, build upon or sell, so long as they attribute the developers on whose shoulders their work stand. Hardware can also be expanded to encompass other non-digital input to research such as chemicals, cell lines and materials and a growing number of open science initiatives are actively sharing these with few or no restrictions on use.
  89. Despite its importance in research, (open) hardware making is not recognized in academia, yet. While we see pioneering approach to publish data and software related to a research article (see https://blog.datadryad.org/2021/02/08/doing-it-right-a-better-approach-for-software-amp-data/), there is no dedicated publication system for hardware, and no direct mention of hardware in the DFG codex `r citep("10.5281/zenodo.3923602")`. Even in the CREDIT initiative that want to create incentives for non-traditional contribution in research `r citep("10.1080/08989621.2020.1779591 ")`, hardware making has been left out.
  90. Accordingly, there is no incentive and few tools for researchers to provide documentation for their hardware design.
  91. Research data and software are in contrast published using specific licenses, specific platforms (Dryad and zenodo for example), specific evaluation mechanisms (data curation and software review), and the community is recommending the citation of these instances instead of the research paper (`r citet("10.12688/f1000research.26932.2")`, see WP2 for more details).
  92. As a consequence, the publication of datasets and software start to be recognized as an important research outputs (see guideline 13 of the DFG codex `r citet("10.5281/zenodo.3923602")`). Recently emerging open hardware maker communities would like to see a similar development for hardware, and it started with the development of evaluation mechanisms for open hardware.
  93. In research (projects), defining quality criteria as part of hardware development requires to consider issues such as project goals, stakeholder needs, regional and sectoral contexts (environmental, socioeconomic, geographical, cultural). These are then translated into technical requirements against which technology is prototyped, demonstrated, optimized and/or qualified. Presently prevailing proprietary logic in academia leads for the validation of requirements' fulfillment to occur within project boundaries. Hardware development according to OH and FAIR data principles presents additional requirements such as transparency, accessibility, replicability. The latter refers in particular to the resulting hardware `r citep("10.5334/joh.7")` and presents a critical factor for RRI and a putative high return of investment for the society `r citep(" https://doi.org/10.1093/scipol/scv034")`. However, a key question on open, FAIR hardware in recent years has been to ask "how open" it is `r citep("10.1016/j.procir.2018.08.306")`. As the only viable way to answer this question, independent hardware evaluation is an important enabler that can lend credibility to open, FAIR hardware in academia and thus unlock its untapped potential.
  94. ### Project objectives
  95. In order to unlock the potential of open and FAIR hardware for academia and beyond, the project **general objective** is to prototype and demonstrate methods and tools for the documentation, evaluation and publishing of open, FAIR hardware. This will facilitate responsible research and innovation and establish new career paths for researchers. We have defined four specific objectives:
  96. **Specific objective 1**: Create a prototype for a hardware publication system, in order to build the foundation for a recognition of hardware making skills in academia . This involves:
  97. - the creation of an evaluation system specific for FAIR and open hardware (WP1-2).
  98. - the adaptation of publication pathways used for data and software, inside a FORCE11 working group to be created (WP2).
  99. - the verification of developed solutions within ongoing hardware projects of the partners, in the fields of automation, medical device, physical metrology and virtual reality applications (WP2).
  100. - the exploration new incentive mechanisms (independent of journals) for the production of better hardware documentation in academia, irrespective of the research domain (WP2).
  101. **Specific objective 2**: Provide researchers with tools to guide their work along the whole process of open and FAIR hardware design (WP3). This includes:
  102. - The analysis of current workflows in hardware design and dissemination, their successes and shortcomings (WP1)
  103. - A dissection the certification process of some chosen hardware pieces in neuroscience, robotics, medicine, and physics.(WP2)
  104. - The production of open education resources, in particular an open book similar to the turing way book (`r citet("10.5281/zenodo.3233853")`, WP3).
  105. **Specific objective 3**: Pro-actively cooperate with other relevant projects, actors and initiatives on the wider establishment of evaluation procedures and indicators of open, FAIR hardware. This includes:
  106. - the creation of a new FORCE11 Working group (WP1)
  107. - discussion about the development of metadata specific for hardware (WP2)
  108. - the co-development of tools to favor a better curriculum in hardware production. (WP3)
  109. - close collaborations with the open source hardware association and the Gathering for Open Science Hardware communities. (WP1-2-3)
  110. ### Open science and quality control
  111. <!---
  112. ~~While being mostly developed for the quality control topic of this call, this project also covers some aspects of the open science line.~~
  113. - line 1:
  114. - quality control
  115. - interdisciplinary
  116. - evaluation tool
  117. - new indicators
  118. - line 2 open science:
  119. - analysis of current practices in hardware creation
  120. - open practices in the dissemination of hardware documentation (license, publication)
  121. - prototyping tools to get independent from publishers (open infrastructure)
  122. --->
  123. The project Open!Make fully addresses Line 1: Research Quality and specific aspects of Line 2: Open Science, as part of implementation and through actions for impact maximization.
  124. #### Responses to Line 1: Research Quality
  125. **Area 1: Research quality in different disciplines**:
  126. Hardware development requires for it to be continuously documented, in order for the resulting technology to serve as an exploitable result. This project will bring incentives and an evaluation system to **motivate and monitor the production of FAIR hardware**, which will eventually raise the quality of the hardware produced.
  127. Traditionally, publicly funded research projects tend to seek IP protection through patents, design and trademark application. While this is common practice, RRI involves holding research to high ethical standards including the reproducibility of research results.
  128. This project will enable researchers and joint research projects to easily publish hardware according to FAIR data principles. This provides an **alternative to IP and a sustainable path** that ensures unhindered reuse of products by any actor interested in making use of and benefiting from these resources. Moreover, verifying developed solutions within ongoing hardware projects of the partners in the fields of automation, medical device, physical metrology and virtual reality applications will ensure that **different disciplines are taken into account**. These include biology, neurology, medicine and physics among many others.
  129. **Area 2: Evaluation and assessment procedures**:
  130. We will create **new processes and infrastructure for the evaluation of hardware replicability** and publication of product- and process-related documentation. While the former develops qualitative methodology to assess the conformity of hardware with OH and FAIR principles, the latter allows to attribute individual contributors of research outputs from hardware making. Since such research outputs are largely unrecognized in academia, this will lead to new quantitative indicators beyond the visibility of published research articles.
  131. #### Open!Make’s responses to Line 2: Open Science
  132. **Area 1: Funding of open science practices**:
  133. We will create **evaluation criteria for the quality and openness of hardware produced in research**. This will bring hardware at the level of datasets and software in university and researchers indicators, allowing research funds to include new criteria in their choice of funding, promoting open science and open hardware practices.
  134. We will **support an Open Hardware Makers Curriculum** by creating guidelines on the documentation, evaluation and publishing of open, FAIR hardware.
  135. In addition, we will promote the use of **open infrastructures** (independent from publishers) to review and publish open, FAIR hardware, so that we restrict the cost associated with hardware publication.
  136. **Area 2: Analysis of disciplinary framework conditions for open science**:
  137. As part of the needs analysis for the project's solutions, we will monitor current practices in open hardware practices, as well as consider motivations of researchers. In addition, we will also look into processes of hiring hardware makers in the labs, looking for ways to improve the adoption of open hardware in the community.
  138. In addition, we will map national and international standards for technical documentation and open hardware sharing and promote international consortium dedicated to build a better framework (FORCE11).
  139. #### General call requirements
  140. With this practice-oriented project, the Berlin University Alliance will create a center of competence in Berlin for the development of novel standards and tools for hardware documentation and publication. The partners are moreover keen to cooperate with BUA Objective 5: Sharing Resources and the BUA Cross Cutting Themes on issues such as diversity, gender, teaching, and internationalization.
  141. ## Einordnung des Vorhabens in den aktuellen internationalen Forschungsstand (maximal eine Seite bzw. 3,500 Zeichen inkl. Leerzeichen)
  142. Open Hardware is a practical phenomenon that was created by grassroots communities at the start of the century. Important steps in the consolidation of the field have been the founding of the OH community projects: Open Source Ecology for a global village construction set in 2003 (OSE, http://opensourceecology.org/); Arduino for low-cost microcontrollers (https://www.arduino.cc/) and RepRap for DIY 3D printers (http://reprap.org/), both in 2005; the introduction of CERN's Open Hardware Repository for collaborative OH development (OHWR, https://ohwr.org/) and CERN's Open Hardware License (OHL, https://ohwr.org/cernohl), both in 2011; the formation of the Open Source Hardware Association (OSHWA, https://www.oshwa.org) in 2012; and the formation of the Gathering for Open Science Hardware community (GOSH, http://openhardware.science/) at Cambridge University in 2016 promoting the democratization of science by DIY ("Do It Yourself") hardware.
  143. Interest by the research community has been growing steadily since the mid-2000s. In recent years, dedicated journals have been founded like the Journal of Open Hardware and HardwareX (Elsevier) and there have been special issues / thematic collections in journals such as: Human-Computer Interaction, Design Issues or Design Science. Yet, the topic still remains relatively understudied and unknown in science and industry. Given the potential contribution of the open hardware approach by collective action at the forefront of societal needs and trends such as circularity and the creation of a bioeconomy, there is however a great need for empirical research.
  144. This project will create synergies with ongoing research in the H2020 project OPEN_NEXT coordinated by TUB (https://opennext.eu/, grant agreement no. 869984): Among other things, the partners are carrying out research on facilitating design reuse of OH in industry; and demonstrating an open graph database to facilitate design reuse through (semi-)automated structuring of OH modules called Library of Open Source Hardware (LOSH, https://github.com/OPEN-NEXT/LOSH). We will also work with the Open Knowhow initiative (by MakerNet in which TUB has participated since its foundation in 2019, https://openknowhow.org/), which provided a published metadata standard to enhance the discovery of OH on the Internet.
  145. This project will also apply and use different toolbox and advances in software and research data publication. We will introduce the open hardware problematic into the FORCE11 communities (https://force11.org), that elaborated the FAIR principles and is active in all scholarly communication activities (including for example sustainable research software initiatives, contributor role taxonomies). On the other hand, specific group in the research data alliance (https://www.rd-alliance.org) have been working on data and software citation, and we will team up with them to design hardware citation recommendations. We will also searched collaboration with NFDI programs, especially the NFDI-neuro program
  146. (www.nfdi-neuro.de).
  147. We will also closely work with the Open Hardware Makers program, spin-off project from the GOSH community (https://openhardware.space/). This mentoring program that been continuously developing a curriculum on the basics of open hardware targeted at newcomers (practitioners, makers, but also researchers).
  148. ## Work program and milestones
  149. <!---Detailliertes Arbeitsprogramm einschließlich der geplanten Meilensteine, Ausführungen zum me- thodischen Vorgehen (einschließlich einer diesbezüglichen Risikoabschätzung), zur theoretischen Rahmung des Vorhabens sowie gegebenenfalls zum Feldzugang (maximal drei Seiten bzw. 11,000 Zeichen inkl. Leerzeichen)
  150. --->
  151. ### Overview
  152. Achieving the objectives of Open!Make requires continuous collaboration and inter-disciplinary exchanges between the three partners throughout the entire project period. To attain this, the team will establish a structured, collaborative and transformational way of working that seeks to steadily move towards realizing its ambitious goals while keeping a close view on the risks and challenges.
  153. Open!Make’s working program consists of three work packages (WPs) building on each other like a staircase. WP1 will deliver the necessary groundwork by identifying and analyzing representative use cases, best practices of open and FAIR hardware development in academia and researcher needs. WP2 continuously transforms identified needs from WP1 into requirements for methods and tools for evaluating and publishing open and FAIR hardware in academia and implements them. WP3 complements WP2 by testing the developed solutions in practice, providing associated guidance, developing education resources, engaging in standardization and building awareness.
  154. The overall methodology of Open!Make consists of three stages, whereby each stage is designed to leverage external involvement espousing the participatory nature of the project’s research object. Each WP kicks off a new stage of the project from (1) the research phase, to (2) the Prototyping and testing phase, to (3) the impact maximization phase, each lasting nine months.
  155. Along the project, we will use three specific hardware as use case. We will first analyse how they were documented and disseminated, then use them to test the evaluation and publication system and finally publish a peer reviewed, open FAIR version of these three hardware:
  156. 1. The Airtrack system (HUB, `r citet("10.1152/jn.00088.2016")`) has been developed in 2016 in the Larkum lab and was has been rebuilt several times in the USA (Adam Kepec and in Dieter Jaeger), Australia (Lucy Palmer), in Germany (Kremkow) and in United Kingdom (Andy King). We will analyze the process and especially differences between the five dissemination.
  157. 2. robofish `r citep(" 10.1098/rsbl.2020.0436")`
  158. 3. open imaging
  159. ### WP1, L:TUB, P:HUB, FUB Research phase [M1 - M9]
  160. **Methodology**
  161. This phase will build a shared knowledge base for the project through a mixed-method approach of data triangulation. On the one hand, an interview campaign and an online survey will deliver a better understanding of opportunities and shortcomings of open, FAIR hardware practices in academia. In particular, we will find and contact researchers (half of them Berlin-based researchers of any discipline) who are active or interested in open, FAIR hardware development and conduct semi-structured interviews. The survey will focus on issues such as process and tools used/desired, researcher needs, pain points and their habits in the documentation and dissemination of the hardware. On the other hand, we will carry out ethnographic research on relevant use cases of several hardware pieces that are being developed in the partners labs / workshops, how they were designed, documented and disseminated (see below). Cross-analysis of the complementary datasets will allow a balanced picture and crystallization of findings.
  162. We will also seek for additional partners and grow an international networks of OH enthusiasts (the gathering of open source hardware), scholarly communication professionals (FORCE11), and data management specialists (RDA).
  163. **Activities**
  164. T1.1 Survey (HUB)
  165. T1.2 Interviews (TUB)
  166. T1.3 Ethnographic study (FUB)
  167. T1.4 Transforming needs into technical requirements
  168. D1.1 requirements analysis --> D1.1
  169. **Expected outputs:**
  170. - FORCE11 interest group
  171. - Blog post(s) on the FORCE website, or elsewhere
  172. - dataset of interview analysis
  173. - dataset of survey analysis
  174. - dataset of use cases analysis
  175. Prototyping and testing phase [M9 - M18]
  176. ### WP2, L:FUB, P:HUB, TUB
  177. T2.1 Architecture analysis (FUB)
  178. T2.2 Prototyping of evaluation system (TUB)
  179. T2.3 Publication and citation extension (HUB)
  180. T2.4 Testing of feature frozen version (FUB)
  181. D2.1 Prototyped and tested system
  182. #### a) Evaluating open FAIR Hardware
  183. While datasets evaluation is very domain specific and often require the involvement of data curation specialists and/or automated verification of metadata models, the use of the FAIR principles `r citep("10.1038/sdata.2016.18")`has been a catalyst in the creation of data curation workflows. In contrast, research software peer review is an emerging field, where communities ( `r citet("10.5281/zenodo.2553043")`, JOSS, ISSN 2475-9066) have built their own standards and workflows, based on the GitHub platform. Similarly, OH communities have build evaluation principles for open source hardware.
  184. > to be completed extensively by Robert :)
  185. #### b) Publication system
  186. In addition to quality control, a publication system should provide recognition to the contributors who worked on the project, a long term archive of the research results, a registration of the work (allowing people to find it), and awareness. In addition, usage rights needs to be clearly specified, as to follow the FAIR principles. Last but not least, a publication system for non-traditional research outputs should be easy to use, and possibly get integrated in the workflow of the researchers. We will therefore look in priority at tools that can be implemented using a git platform workflow, as for software peer review. This has the extra advantage to be a tool well known from IT departments at the HU, FU and TU.
  187. **Registration and awareness** depends on the use of a metadata model that is used in the targeted community. We want to expand the metadata model used for most data and software publication, i.e. the datacite model and/or [the schema.org model](https://schema.org/), using the Open Knowhow initiative metadata as a starting point. This would allow for efficient hardware discovery tools, similar to the tools in development for datasets (see https://www.go-fair.org/implementation-networks/overview/discovery/).
  188. We will consider different tooling to provide **long term archive** of the hardware publication, as it will depend on the tools used for documentation and evaluation. For instance, we may follow a GitHub (for documentation) to zenodo (for archive and publication) path, similar to the one used for software. However, we will promote a workflow using open source software and university library tools (either a GitLab to Dspace, or a GIN pathway, that are preferred for datasets publication), since the use of an open infrastructure that can be decentralized will be more sustainable.
  189. <!---
  190. The publication system will be integrated inside a platform and workflow using a git version control system. Indeed, a large part of the community is already using them, and the evaluation system can be integrated to these platform easily.
  191. --->
  192. We will also provide an efficient way to choose and **apply a license** to the hardware.
  193. > This needs your inputs Robert!
  194. In order to build the foundation of a **recognition system**, we will prototype a badging system for hardware and their makers, using open badges `r citep("https://www.imsglobal.org/activity/digital-badges")`. Additional tools like continuous integration and banners will also be considered. In particular, we will follow progresses in providing extra recognition for dataset and software, looking especially at tools integrated in researcher's orcid profiles.
  195. #### c) Use cases
  196. We will run the hardware pieces chosen as use cases in the WP1 through the evaluation and publication process. This will allow us to refine the tools and demonstrate the efficiency of our approach.
  197. #### Expected outputs:
  198. - Workflow for the evaluation and publication of hardware at the BUA
  199. - Metadata model for hardware publication
  200. - At least three hardware published as use cases
  201. - Report on the basic infrastructure requirements to enable documentation, evaluation and publishing of open, FAIR hardware as an open infrastructure project.
  202. ### WP3, Impact maximisation phase (HUB) [M12 - M24]
  203. T3.1 Organise open book writing, (guidelines for OS hardware making) (HUB)
  204. T3.2 How-to Documentation (FUB)
  205. T3.3 Technical standardisation (TUB)
  206. T3.4 Organisation of an international scientific and practitioners workshop/conference (HUB)
  207. T3.5 Publishing of research papers (FUB)
  208. T3.6 "Placeholder task" how to adapt for campus IT infrastracture (HUB)
  209. We will partner closely with the Open Hardware Maker Program to provide open education resources for hardware making. We will complete their knowledge with specific problems and best practices that we will identify during
  210. the analyses of workflows and use cases in WP1, and during the evaluation of hardware in WP2.
  211. We will co-organize specific workshop for makers at the BUA, and organize the redaction of an open book, using a technology, workflows and principles similar to the one used for the redaction of the turing way book `r citep("10.5281/zenodo.3233853")`. We will also provide researchers with one or several templates and checklist that could guide the organisation of their files. We will develop these tools iteratively including community feedback at different stages of the process, imitating the successful strategy used by the GIN-Tonic team `r citep("10.25815/WCY6-M233")`.
  212. During this phase, we will also develop an implementation strategy, finalizing our discussions with libraries and IT infrastructure in order to provide a sustainable instance of the open source hardware publication system.
  213. ## Angaben zu Verwertungsmöglichkeiten und -planungen; hierzu zählen Nutzungsmöglichkeiten der Ergebnisse in der wissenschaftlichen und nicht-wissenschaftlichen Öffentlichkeit (maximal zwei Seiten bzw. 7,000 Zeichen inkl. Leerzeichen)
  214. In the project, we will help define best practices in hardware making, and ways to measure the quality and openness of hardware. This will be the basis for the creation of a hardware maker curriculum. It will lead to the creation of new content to teach. This content will be leveraged by free-lance teachers. We will indeed provide such workshops during the third phase of the project.
  215. On the other hand, it will also probably lead to the creation of new master classes on a longer term. Indeed, efforts in the definition of good data management has brought a new career path for data managers and stewards, and it lead to the creation of the specific master in digital data management at the HU (https://www.ibi.hu-berlin.de/de/studium/studiengaenge/ddm-master). We foresee the development of similar curriculum for OS hardware in the near future.
  216. During the project, different hardware pieces will be evaluated and published as open source hardware. This will maximize their reuse in the scientific community.
  217. We will provide the basis to create a monitoring of hardware making activities in universities. This will allow the development of new algorithms and software that will create new metrics for academic successes.
  218. Open source hardware is a pillar of open innovation and our work will be therefore used outside academia.
  219. ## Darstellung der praxisrelevanten Forschungsergebnisse sowie Konzept der Implementierung (maximal zwei Seiten bzw. 7,000 Zeichen inkl. Leerzeichen)
  220. Our hardware publication prototype will be based and released as an open source software. This allows for libraries and universities IT department to provide their own hardware evaluation and publication pathway, especially as most universities already provide a GitLab instance, and are therefore used to provide similar products. We will indeed approach IT department and libraries at the BUA to prepare such implementation of the developed toolbox, in order to provide a sustainable open infrastructure for OS hardware at the BUQ
  221. <!---
  222. - Report: bad and best practices (blog post, publication in diamond open access)
  223. - Final report in a diamond open access journal
  224. - Publication platform prototype as open source software(s)
  225. - runnig platform in collaboratiom with one bibliothek
  226. --->
  227. ## Cooperation concept
  228. <!---Konzept zur geplanten Kooperation mit den Projektpartnern, bspw. Beschreibung der Arbeits- bzw. Aufgabenverteilung, Angaben zum wechselseitigen Mehrwert (maximal eine Seite bzw. 3,500 Zeichen inkl. Leerzeichen)--->
  229. We plan to cooperate in this project using the same principles we used to write this document.
  230. Our objectives can only be achieved with the expertise of the three labs involved in the project, and every work program will be performed in a collaborative manner between the 3 teams. Nevertheless, the TU team will lead the development of the hardware evaluation process, the FU team will lead use cases analysis and publication, and the HU team will lead the international networking, survey processes, and scholarly communication aspect of the project.
  231. Discussions and exchanges between the partners is primordial in this project, as each team is bringing a different expertise, each of them being necessary for the success of this ambitious project. We
  232. We will also actively seek for additional collaborators and expertise, as well as international networking during the project. We will for instance coordinate our work with the gathering of open source hardware to create a FORCE11 interest group, and/or a RDA working group at the beginning of the project, in order to obtain additional feedback and visibility.
  233. ## Reseach data management plan and publication strategy
  234. <!---Beschreibung der geplanten Maßnahmen zum Forschungsdatenmanagement und zur Publikations- strategie. Publikationen und Forschungsdaten sind kostenfrei zugänglich zu machen. (maximal eine Seite bzw. 3,500 Zeichen inkl. Leerzeichen)--->
  235. This project will be run using an open research methodology, where data, results, discussion and ideas will be shared in an open repository on GIN (gin.g-node.org/), using a standard research folder organization `r citep("10.25815/WCY6-M233")`. raw (or ) datasets will be made available with a CC0 license upon collection, or as soon as legally possible. Data will be curated, and its analysis will be preformed using reproducible reports, in order to facilitate re-use. Upon publication, the whole repository will be archived and published via the GIN platform.
  236. Hardware will be published following the workflow developed in this project, under an open source license for hardware.
  237. Intermediary reports will be published on blog platforms specialized in scholarly communication or hardware makers (depending on the topic of the report). Manuscript will be uploaded in a preprint server before submission to a journal. Following plan S, only gold and diamond open access journal (offering CC-BY license and copyright retention by the authors, and being in the DOAJ index), will be considered as host for our outputs, the latter being preferred.
  238. ## Referenzen - Please list your literature references.
  239. <!---
  240. ## Sollen aus dem Forschungsvorhaben resultierende Ergebnisse als Beitrag in einer wissenschaftli- chen Zeitschrift veröffentlicht werden, so soll der Öffentlichkeit der unentgeltliche elektronische Zugriff (Open Access) auf den Beitrag möglich sein. Erscheint der Beitrag zunächst nicht in einer der Öffentlichkeit unentgeltlich elektronisch zugänglichen Zeitschrift, so soll der Beitrag – gegebenenfalls nach Ablauf einer angemessenen Frist (Embargofrist) – der Öffentlichkeit unentgeltlich elektronisch zugänglich gemacht werden (Zweitveröffentlichung). Im Fall der Zweitveröffentlichung soll die Em- bargofrist zwölf Monate nicht überschreiten.
  241. ...
  242. ## Im Rahmen des Projekts sollen gewonnene Daten mit etwaiger Relevanz zur Nutzung durch Dritte nach Abschluss des Projekts in weitergabefähiger Form auf der Basis gängiger Standards einer geeig- neten Einrichtung/einem Forschungsdatenzentrum zur Verfügung gestellt werden. Ziel ist, die lang- fristige Datensicherung, Sekundärauswertungen oder eine Nachnutzung zu ermöglichen. Gängige Anforderungen an das Forschungsdatenmanagement sind zu berücksichtigen.
  243. ...
  244. ## Anhang: Kurze CV der beteiligten Projektleitungen, Publikationsliste mit maximal fünf themenbezo- genen Publikationen der letzten fünf Jahre je Projektleitendem, Angaben zu einschlägigen For- schungsprojekten bzw. laufenden Drittmittelvorhaben mit Titel, Förderer und Umfang, gegebenen- falls Unterstützungsschreiben / LoI der kooperierenden Partnerinstitutionen (maximal fünf Seiten).
  245. Insgesamt sollte der Projektantrag zwölf Seiten nicht überschreiten (ohne Finanzierungsplan und Anhang).
  246. --->
  247. > references will be created directly in the pdf when inserting the r code and doi (see top of document)
  248. > Perfect, thanks!
  249. ```{r, echo=FALSE, message= FALSE}
  250. write.bibtex(file="references.bib")
  251. ```
  252. ### 5 pager for CVs etc.
  253. Upload a short CV of each applicant (excluding cooperation partners) including a publication list with maximum 5 publications relevant to the project's topic from the last 5 years.
  254. Also add information to relevant finished and current research projects, including title, funder, funding amount, start date and duration.