this thread a tiny tiny example of why this is hard to do and how architecture of a tool is not neutral to the kind of use patterns it supports. (the STS ppl will roast me for saying the obvious) https://twitter.com/auto_pi_lot/status/1478986353408811008?t=ZTzF-7XnYPgSCwI-ThBakw&s=19

this is critical for collaborative science: often you will need to integrate with some established brittle LabView system based in a different OS, so being able to deploy a tiny headless raspi that can take and give arbitrary signals can mean doing vs not doing an experiment

and if the knowledge system surrounding a tool means you need to spend 50 hours frustrated on stackexchange without means of recording what you learned, you multiply the work of that integration by everyone who needs to do something similar

this semantic wiki model is particularly good for making partial-match knowledge discoverable, someone doing something close but not *exactly* what you're doing shouldn't mean you start from scratch. finding code by motor type, sensory modality, or any dimension is v powerful

particularly when the barriers to contributing code is much lower than a pull request. or even a specific code structure! like just fill out a form and take notes on a wiki Article and someone can find and use your stepper motor driver class!

idk I think it is cool and it has helped my work and have tried to make it easy to use but I could be wrong about literally everything and am always open to criticism.

if we want to break down papers as the fundamental unit of scientific knowledge, uniquely unfit for local technical knowledge like this, I think investing in alternative communicative systems is necessary, and by linking them with practical tools we might even make it useful.

I am a little (a lot) wiki-pilled, but if I don't see an edit button on a platform I wonder how it plans to incorporate this kind of intrinsic variability in experimental needs that literally defines the problem