Open Microscopy 2023

# Open Microscopy 2023 ## Collaborative notes Link to Slido: https://app.sli.do/event/acmsZxPaZj8wScFHUXvdXB/ Code: #M2223 ### DAY 1 #### Panel 1: Open hardware reaches further - Dr. Catherine Mkindi [link to presentation] - Dr. Jenny Molloy - [link to presentation](https://docs.google.com/presentation/d/1QIee8adRBfVdbVrmjmgTlj9CZkp-rWGauRQLvLnr_4c/edit) - Professor Dan Fletcher [link to presentation] #### Unconference 1 topics 1. Funding and sustainability (Facilitation: B. Diederich) > **Short summary here or picture of notes** 2. IP vs Open Source (Facilitation: P. French, S. Faez, A. Katz) - Perceptions and practices of TTO: there seem to be a disconnection between the understanding of the researchers and TTOs on the usefulness of IPs and various paths to create social impact from a researcher's innovation. While legally, researchers are asked to declare their inventive ideas, the usual path of IPs and licensing does not generally create the impact researchers want to make, and not always compatible with open science practices. - The issue if exclusive licensing seems to be at severe conflict with dissemination of knowledge created by public investment. The very small chance of unicorn companiess spinning out of university research does not seem to justify the huge cost and down sides of secrecy and exclusive licensing. - A new, wider definition of impact can change the practices of researchers and TTOs alike. For example how impact is reported in evaluation cycles or special topics such as those connected to urgent societal issues such os UN SDGs might enable alternative commonly accepted routes of bringing out academic innovations through open science routes, instead of IP protection, exclusivity and secrecy. - Some participants go as far as advocating for banning exclusive licensing for publicly funded research and and to use the language of impact and contribution to common good instead of valorization and economic revenue. This might require embracing new terminology and academic pledges. 3. Compatibility in Open Science Hardware (OSH) (Facilitation: R. Bowman) Compatibility was discussed in between software and hardware, as well as in terms of compatibility between hardware systems (e.g. for a connected suite of equipment) and within systems. The point about standardisation has been raised as a main point that is required, looking beyond standardisation of for example communication protocols but also for standardised commands on communication links between equipment. Machine vision cameras and their interoperability ([GenICam](https://www.emva.org/standards-technology/genicam/)) was mentioend as positive example in this direction. Modularity of parts and software is key and questions were raised if there are ways for the community to build generic drivers and currate lists of compatible elements that work with them. Approaches of how to deal with compatibility were mentioned (e.g. Thorlabs using Arduino with custom firmeware flahes as abstraction layer between hardware and python control; e.g. OpenFlexure using an HTTP server with documentation complying to [OpenAPI] and [Web of Things] standards). One vision for the future was individual hardware components integrating cheap small controller with wireless connectivity to be able to link into larger standard communications/access protocol. [OpenAPI]: https://www.openapis.org/ [Web of Things]: https://www.w3.org/WoT/ 4. User perspectives in OSH (Facilitation: F. Whiteford) > ![notes written by Prof. Gail McConnell](https://hackmd.io/_uploads/rkTNaqXIh.jpg) #### Panel 2: Faster, more reproducible instrument development - Dr. Rifka Vlijm - Professor Paul French - Dr. Lin Wang - Dr. Johannes Hohlbein #### Unconference 2 topics 1. Learning from open source software (Facilitation: A. Katz) Huge difference between OSS/OSH. OSS is successful due to a combination of access to internet, tools like git, toolchain availability. This is not available in OSH, needs to be made out of IRL materials, which is a barrier. Reproducibility isn't perfect. All this is a challenge for OSH communities. What can be done? - Awareness about OSH potentials - collectively demanding a component - lack of tools: full collaborative toolchain that is not text based, make it easier 2. What to open, how and when (Facilitation: J. Stirling) If totally open, risk of appropriation by players with more resources. How to open: temporal dynamic if you are working openly continuosly, or release, or one time. There was discussion of how to manage versions, what constitutes a "release". A release should be understandable, repeatable, discoverable, and continuable (sure i've missed one). 3. Skills and capabilities (Facilitation: P. Christopher) Different levels of skills: - being able to interpret instructions - to build - ability to modify, repair - implementation of OSH to their research questions Loss of knowledge transfer from dev to user. Retention of knowledge in research groups is a problem due to high rotation. Need more funding for tech research staff. Improving or foster interdisciplinary, e.g. phd training partnerships. Generalised vs specialised expertise. High skill users that are not proficient with the instrument. Higher quality documentation, backing up docs practices in journal/funder reqs when publishing OSH. Users/dev matchmaking skills. 4. Funding and journal requirements (Facilitation: R. Bowman) Does industry value openness? No, with few exceptions. Challenges with IP and publication. Many interactions between academia and industry are dominated by IP acquisition. Should default be open? Do we need a FAIR for hardware? There's a [group working on FAIR principles for open hardware](https://www.rd-alliance.org/groups/fair-principles-research-hardware) with a [2021 preprint](https://arxiv.org/abs/2109.06045). Impact? Can be hard to capture, at least compared to the more conventional path of licensing to a company and collecting royalties. Number of users isn't a proper indicator, changes over time. Impact *is* about more than just financial return, but requires work to articulate. Funders (at least in UK) have pushed for data and publications to be as open as possible, as closed as necessary. We felt this would be a very reasonable principle to apply to hardware. Suggestions inlcuded requiring a justification if hardware is not to be shared, and developing a hardware accessibility statement along the same lines as data accessibility (e.g. the hardware developed in this manuscript is openly licensed/confidential pending a patent, or stating whether it has been independently reproduced). Journals are unlikely to unilaterally impose openness, but at least some already verify openness if it's claimed, e.g. checking software repositories. #### Unconference 3 Topics ##### Modularity, modifiability, and interoperability How do we make it possible (and easy) to customise and improve open designs, and how do we connect projects together in hardware and software? The top-level summary of this session is that the most important thing we can do, for each project, is make sure that the interfaces (software, optical, mechanical, electrical) are documented. Where are the mounting holes? Where's the focal plane? How do I control it from micromanager or Python? There are some de facto standards that have emerged (e.g. 30mm cage system) and some intentional standards (e.g. c mount) but ultimately hardware adapters or software shim code can be made if the interfaces are defined well. What level of modularity do we need/want - how does this vary for users/developers There are different levels - being able to swap in/out particular components, or whole modules (illumination/imaging/translation stage). What’s the “hardware API” between components - e.g. C mount, ThorLabs cage system. Do we want to go further and describe it in terms of where the image/Fourier plane goes? C mount already specifies that. It’s really helpful if projects can explain how to extend/modify them. For example, where are your mounting holes? How can you determine whether this changes from version to version? That would already enable better integration - even if we don’t standardise, we can still document. Modularity often needs standards - metric or imperial screws? Could we review standards that are emerging? Collaborative review article for the proceedings?? Do manufacturers have existing standards? RMS used to make life quite simple - still need to refer back to standards. Defining the image plane locations is incredibly helpful. A well documented API is already very valuable even if it’s not standardised. If you document your system (e.g. provide CAD of the interface points) it will enable interoperability even if someone needs to make a little adapter of some sort. De facto standards like cage system will emerge - so it can be useful to think about how you’d connect to that even if you’re not providing the adapter yourself. True interchangeability might need electrical, mechanical, optical interfaces between different systems. For optics, we probably need to document apertures (NA, image size) to help determine compatibility between different systems. Could we persuade commercial manufacturers to provide this data? It would be so helpful for customisation. Many commercial bodies are not modular - so less incentive to share customisation information. Modular systems like Cerna (ThorLabs) ought to be easier to find the documentation for. Companies are competing between themselves - sharing information might weaken competitive advantage? It could just be cost control, it’s not worth paying someone to document this. It was pointed out it is still possible to get information under NDA - e.g. for accessory manufacturers. Maybe reluctance to share this with academics stems from the potential support burden. Often individual developers at companies would not see any reason not to share information - but they may be restricted by compliance/legal constraints concerned with contractual liability. Could we write an open letter to manufacturers setting out what we’d need? There are many systems represented here, and far more outside the room. Can we pull some of these together - how can we collaborate or coalesce on software, hardware, both? **Software** Could we ever imagine a situation where non-programmers can combine different hardware modules and the corresponding software to put things together? This is already possible for e.g. ImageJ macros that enable image analysis pipelines to be created and used without coding. There’s already modularity within some projects - e.g. UC2 cubes, OpenFlexure interchangeable optics modules. The UC2-OpenFlexure interface came about when we talked in the forum: in the software world APIs are usually there to start with. Software can be challenging - particularly hardware control and synchronisation. Better interfaces between existing modules would help here - Richard suggested OpenAPI is a really helpful and flexible standard for this. A big help is that there’s lots of existing tooling/libraries to support it, maintained by lots of professional developers because it’s used for web apps (rather than being specialist for scientists only). Open tools like Arduino are also emerging as useful standards - e.g. Arduino or Arduino-compatible controllers used to provide synchronisation. Some commercial providers have nice sequencing interfaces - some open projects try this with e.g. blockly but those interfaces aren’t fully general (yet). Micromanager can run some sequences, we weren’t sure how graphical/friendly this is. Synchronisation, concurrency, data handling can all be hard - how do we provide ways to make this easier? How do we get multiple projects to share the same framework/interface? Next week we’ll have Henry Pinkard who is very involved with micromanager/pycromanager, we won’t solve this then but perhaps it’s a good jumping-off point. If we have existing monolithic/proprietary scripts, should we change? Will it work better? It can make it easier for new lab members to continue development if you’re using something standard. If you’re pushing the envelope with timing/synchronisation, moving to a new framework can be a lot of work! LabVIEW is a bit “marmite” here - it can make it very easy to get systems working, but it can be very hard to maintain and debug. It’s also decreasing in popularity as a training language. LabVIEW can be integrated with other code (including by HTTP) but it’s tricky. LabVIEW blocks are often supplied by manufacturers (especially if it’s NI hardware) and that improves inter compatibility. The interface can be great for concurrent programming - and parts of it may now be open (?). We discussed whether LabVIEW could cope with real time image processing - the Vision toolkit has quite a bit of stuff. However, there are probably more/better tools in the open system (script/opencv/tensor flow). HTTP interfaces are really good for connecting to AI and other advanced analysis - they often exist on servers anyway. Summary * It’s quite hard to agree on standards, though some have evolved/emerged (e.g. micromanager for software, cage rods for hardware) and encouraging their use is good. * Perhaps standardising our interfaces is not so important as documenting them well - that enables adapters/glue code to be developed as it’s needed. That might mean software API docs, or could be provision of CAD files of important interfaces. Challenge * What do we offer that a commercial project can’t do? What does our community offer? - The imaging capabilities will only ever be ahead of commercial instruments briefly - because successful open projects get included in commercial designs. - There *are* cutting edge open projects (OpenSPIM, MesoSPIM) that go (or at least went) beyond commercial state of the art. - Open technologies can be more effectively built upon/extended: the SOTA advances faster and more efficiently when we share designs (but this isn't obvious if we only look at the images). #### Unconference Session 4 ##### Fewer, bigger projects We started by recapping the "Cathedral vs Bazaar" model that's often applied in software. How do we make sure we're not developing the same thing in parallel? How do we make it easier to identify projects that already exist that might help. How might we consider this from a *user* perspective - how do you find things that solve a particular problem with given constraints on cost, function, service, support, etc.? There's definitely a tension here between people and projects considering self-interest vs what's best for individual users vs what's best for the community. Similarly, how do we decide where to invest time - competition or collaboration? Are there other models - e.g. large projects in astronomy or particle physics, or how credit is assigned in large software projects like scipy. How do we reward contributions after initial publication? Awareness, community recognition, citation of otherwise low-impact articles (remember DORA). Interoperability and reproducibility can be improved if we come together as a community to reproduce each others work and offer feedback. There's no obvious conference for open microscopy: do we want a track at Photonics West or CLEO? RMS could host a Focused Interest Group - mailing list, online meetings, a "badge" to raise profile. Forums already exist (like image.sc) where we can carry on the discussion - we don't need something separate. Organisations like global bioimaging can also help, and perhaps CZI could help fund. #### Unconference session 5 topics (online) ##### Micromanager, python, and the future *How will micromanager and python interact in the future? Will this be able to be the all-encompassing microscopy software we are looking for?* Who's taking part (add your name below) - Jacopo Abramo - Henry Pinkard - Nils Norlin - Benedict Diederich - Robert Archibald - Freya Whiteford - Joe Knapper - Rebecca Craig - Paul French - Artemiy Golden Micromanager and projects like it are pillars of the microscopy community so maintenance support is very important but actually doing it is unattractive Commercialisation of Micromanager - is it eg. licensable to end users like universities for support? logistics of doing so and marketing make this difficult It's worth exploring avenues for funding from companies that produce their own adaptors for their products with Micromanager and therefore also rely on it Comparing to other projects whose development becomes "headless" - how do you regain a developer base? how do you direct the project? Ideally, look to collaborations between users so they become invested in the project and can work their way into becoming active developers Shared theme - sustainable funding! Persisting beyond grants relies a lot on the enthusiasm of developers, and "democratic" development has mixed results. We seem to want a "benevolent dictator for life" for consistent direction! It seems to be easier for new, similar projects to get funding over maintenance because they're seen to address immediate problems and have novel applications - how can we make maintenance attractive? Interest in a shared resource base like "staff scientists" or a core facility for software development - could help to avoid constant reinventions of the wheel? Allows for focusing on new features as well as maintenance Discussion about setting up something that's bigger than one lab/company to help with support: could this be pitched to the EU or EMBO? OMERO was supported for ~20 years by Wellcome. Governance: how do you set things up? Micro-manager has adopted the model suggested by numfocus, which suggests "lazy consensus" rather than BDFL (benevolent dictator for life). The intention is to make it more accountable to the community, and more sustainable in the long term. Funding: micromanager is supported through Photomics, which has some core funding for development, and a number of smaller consultancy projects. Is there scope to ask e.g. CZI for another round of core funding? We should make sure that's fed back to Vlad! How do you come up with a modular interface? At the moment, options are to use the Fiji-based interface, or roll your own in Python: perhaps there's scope for something more modular and cross-platform? ##### Future funding/support *How can we support open microscopy in the future? Would a COST action be a good way to support it?* Who's taking part (add your name below) - Sanli Faez - Sebastian Munck - William Wadsworth COST is pan-European, focussed on networks and meetings. https://www.cost.eu/funding/documents-guidelines/ 'Unboxing the black box' Suggest taking the motivation fromthis meeting and also using some of the unconference sessions as potential WP for the action. Additionally make WP on reproducibility and understanding the level of documentation. Authors in recent Hardware X would be a group of potential participants. Investigate the needs of ITN as potential international programme for PhD training. Joining up microscopy development and microscopy application. Cutting edge, reproducibility. It might be worth keeping a conversation open with BioImaging UK around future funding. Kenneth Ho suggested this, but didn't make it to the breakouts. ##### How to decide about commercialisation *How do you decide whether, and how much, to commercialise your open harware project?* Who's taking part (add your name below) - Barbora - Nikita - Fernan - Raj - Richard There's a question for developers - are you keen to work on developing new things, or on maintenance/support. Will you collaborate with a company, or are you founding your own company? It often depends what you want to get out of it - is it just about making something available, or do you want to support someone's time? Do you want to own the business and make a profit? Fernan approached local businesses with the right skills who did consultancy/contract work, and was able to get them to produce things at small scale. E.g. they were able to order ~10s of units. The University wants to support big enterprises, doesn't really understand trying things at a small scale. More expensive projects are hard - if units cost £100k, it's a big financial risk! UC2 looked for companies to support it: they were open, and companies were not happy to engage with an open project because there's no patent. There are some companies willing to engage. Depends a lot on where you're based - perhaps easier in the US? Achieving a reasonable compromise / agreement with a company which is willing to sell an X system, while the X project remains OS. Majority of users want something arriving in a box along with instructions, which may be challenging for high-end OSH scopes, but not impossible (depends on instructions detail). The potential market capacity for DIY scopes is very difficult to estimate. E.g. in poor countries, if there is infrastructure, the institutes will buy commercial big name scopes (Zeiss, etc). If there is no infrastructure, even a 200$ DIY scope will be too expensive. ## USEFUL LINKS TO SHARE ### General - [Non-comprehensive list of projects and resources related to open microscopy](https://github.com/HohlbeinLab/OpenMicroscopy) - [Gathering for Open Science Hardware](https://openhardware.science/) - [Sign Up to GOSH Newsletter](https://openhardware.science/newsletter/) for all open science hardware news and opportunities in your inbox once a month and join the [GOSH forum](https://forum.openhardware.science/) for ongoing discussions. - https://scottishmicroscopygroup.org.uk/facilities-database ### To help you advocate - [Open Hardware is ready to help Technology Transfer Offices (TTOs) maximise the impact of academic research](https://zenodo.org/record/5094999) ### Funding - [Experiment.com low-cost tools for science challenge grant](https://experiment.com/grants/tools), up to $10k grants, closing 31 May - [Open Science Hardware Foundation](https://opensciencehardware.org/), US nonprofit setting up a fiscal sponsor scheme to enable projects to accept funding from foundations, NSF etc without needing to set up their own organisation. Julieta Arancio and Jenny Molloy are on the board, so feel free to reach out to either of us with questions. ### Reports - [Distributed Manufacturing of Open Hardware](https://www.law.nyu.edu/sites/default/files/DistributedManufacturingofOpenHardware.pdf): a Report of the Open Hardware Distribution & Documentation Working Group - [Funding Open Science Hardware Reports](https://openhardware.science/2021-research-funding-salons/)

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.