In my experience, the biggest gains within a creative community come when people do things, and tell others. This might sound self-evident, but I’m yet to see a community where either of those parts couldn’t be improved (a lot). Scientists are no exceptions: while it seems like they supposed to be doing a lot (research) and telling everyone (publications), that’s not the end of the story.
The motto I’ve chosen for Moonpunch at the start was “Do More Science!”. It’s to signify my desire to enable better results overall, because I felt there’s not enough attention & effort paid to how things are done, and undue amount of focus on what is done.
In the commercial sector it is a lot more common for people to share productivity tips, management experience, tools (hardware & software), writing techniques, hiring strategy, and so on, everything that’s needed to get work done. What if researchers would share a lot more of their how as well, the Art & Science of Laboratory Research? Would people be interested learning from each other how to be a better at figuring out the Universe?
It’s very interesting to read a technical book in a field that I actually have some experience built up. (“Some”, though definitely not “a lot” just yet.) Because of that most of the chapters read very quickly, since I was familiar with the concepts, the ideas, the issues, and many of the outlook. It still read very well, and I can see that it should help a lot of people get started, and shortcut a lot of thinking time (boy, how much time I have spent trying to figure out a suitable licensing for hardware designs!)
There were three kinds of content in the book that were especially interesting for me:
The history of open source hardware is a good read – though maybe because I’m not above reading about gossip. :) One can totally do OSHW without knowing how the the current groups came about around it, but the stories make a lot of things clearer, and make me relate to the community much more.
Anecdotes on how teams solved their problems are always very instructive, no matter whether it directly applies to the problems I experience. Sparkfun’s story about how did they have to step up to manage MaKey MaKey reads almost like a thriller. All the problems that arose and how did they solve them. It’s good to stop after their description of each problem along the way, try to answer what would I have done in their case, then read what actually happened. Learn from other people’s mistakes – and successes too.
Finally, the last chapter, Building Open Source Hardware in Academia speaks directly to me. It’s also very well written. Even this book is an anthology with chapters having all different authors, this chapter stands out in style, clarity, and quality of explanations. The experience of author, Joshua M. Pearce as a successful professor makes a lot of difference for sure! The effect of that chapter was very mixed on me: part a rallying cry, part a feeling that I’m already too late to the game in some sense. Either way, it made me think very much about my vision (perfect start for this year’s plan) and now I have a couple of concrete ideas to try, and a clearer language to use to explain things to my academic colleagues (and targets).
By the way, Josh also has an Appendix in the book about Open Source Hardware Security Do’s and Don’ts, I think a lot of people could use such advice – especially if they don’t know that they need it yet.
Now I’ll put this book to the Taipei Hackerspace, and see who else will it help! Maybe even put together a workshop or learning group, and speed up the people who are already making things (there are quite a few, fortunately!)
There is a tingling feeling associated with realizing, that a project I’ve been thinking and talking about for so long, is actually going forward. Even though, this feeling somehow resembles hanging onto a door of a speeding car, trying not to fall off.
Working in a number of physics laboratories (first during my doctorate, then as a post-doctoral researcher), I cannot even recall, how many times I looked at something and felt that “this could be improved.” I don’t know how many times I’ve asked colleagues and fellow professors, what else they needed to get science research done.
Getting science work done quickly and deeply is the way to success for both those who are doing the job and those who are following a calling to explore the Universe. And there are always more things getting in the way.
After asking a lot of questions to the right people, I thought: often there’s not enough money in the labs to buy the equipment they need, instead they have to build it. When they are building it, it’s mostly student work, which comes with its own bugs due to being done by students, which comes with its own bugs due to their lack of experience. The students’ lack of experience is coupled with the lack of communication between groups, which holds back engineering and scientific progress.
And I want to change all this.
This is the beginning of the Moonpunch project, which will enable more people do more science. My head is already full of ideas:
projects for open source hardware and software
DIY laboratory instruments, dedicated maker community
collaboration with successful laboratories and manufacturing companies
…and so on. Having a vision is great, but the biggest issue is focus. I cannot do all that at the same time, since I have to focus to build things up.
While I’m working on this, I feel I need a bit more feedback to make sure that what I’m doing is actually useful. If you are an experimental scientist, please take a few minutes to complete the survey after this post, it would help a lot!
And in the meantime, I’m trying not to fall off this speeding ride…