Flying through some thunderstorm
Some of our learnings from making and flying open science hardware drones
Co-authored with Gustavo Pereyra Irujo
With the help of lots of hands and brains, and funding from Numies, Mozilla Science Lab, and PROCISUR, from June 2017 to January 2019 we (the authors of this post) have been co-leading Project Vuela. More than 40 workshops have taken place in Argentina, Brazil, Chile, Paraguay, and Uruguay, with a ‘crew’ of over 150 people, to first replicate an open source drone, then modify it, and then use it.
In 2017 we started making the Flone, an open drone by Aeracoop (flone.cc), and after the making process (see post), we decided to try and modify that design in order to make it useful for scientific purposes. With the Mozilla mini-grant in 2018 we started prototyping a open source drone toolkit, that could be equally accessible to academy scientists, community scientists, activists, and just about anyone that could need a drone in order to gather data related for their scientific explorations. This work began in our home countries, Chile and Argentina, and then in late 2018 PROCISUR gave us the chance to make and test the new drone, called OVLI (objeto volador libre), with a bunch of researchers in five different countries.
We are also part of a global community (GOSH, the Global Open Science Hardware community) trying to make a big change: we want free, open source hardware to be the default option in science. Such endeavour is much like navigating an unexplored territory: there’s no map, and we have to draw the map as we move and make mistakes.
In 2017 this community outlined its “Roadmap” (next image is a screenshot) but in spite of its name, it’s not entirely a map, but also a compass. It is not intended as a static document (as a map is), but as one that can be revisited and adapted as we work towards our goal. A compass allows us to do just that, adjusting our steps in view of the context we encounter. This is reflected in one of the 3 main sections of the document, called “Learn”, and which emphasizes the importance of constant learning and iteration.
With Vuela we had the same purpose in mind. We didn’t want to just go somewhere, unpack tools and drone components and be satisfied. We wanted to do, observe results, learn, adjust, improve, and not only the drone itself, but also the process of engagement and collaboration among ‘unusual suspects’. Unfortunately, financial and time constraints have impeded us from conducting thoughtful evaluations (which could for example include deep interviewing and ethnographic inquiry). What we did was to discuss impressions after each workshop, take notes, and test new things in view of the immediate perceptions. Here we have compiled some of this learning.
Building an open source instrument, gaining the required confidence to propose improvements, and in this specific case, learning how to fly, takes time, lots of it. And this applies to anyone, no matter the skill set people come with. Therefore, in terms of outcomes of the workshops, we wanted to see a change in perception, from “technology and science is something only a few others can do, the experts, those in universities or working in certain fields, not me”, to “this isn’t as difficult as I thought, I can do it, it is fun, and I can actually contribute my own knowledge”. And, from institution-affiliated scientists going from “this can only be done in a proper lab” to something like “labs aren’t the only place” and “working side by side with lay knowledge is useful, ‘other’ people do know stuff I don’t”. We wanted to push for a more critical stance. We didn’t want at the end of the process to have a bunch of people hooked on drones and obsessed with flying them and make aerial selfies. Instead, we wanted people to realize they could make, use and modify open technology if they decided to, that they could find other instruments that could serve their purposes, adapting them if needed, and redistributing their own learning, somehow.
Well, those were our purposes. But, how did all go?, what did we learn? Of course, good -and unexpected- things happened. But for now, below is a list of 10 barriers we found and some attempts at overcoming them.
1. Language
The problem:
The Flone’s documentation is in Spanish and therefore back in 2017 we thought we were saved, we wouldn’t have to translate anything! But then, who came to our workshops? Mainly Haitian immigrants having recently arrived in Chile, few or none speaking Spanish. They were extremely curious, collaborative and skillful, but communicating was difficult. Language became an even more pressing issue in the second stage, when we started collectively modifying the drone to make it more apt for capturing good quality imagery and serve research purposes, and documenting the process.
How we approached it:
In 2017, we started assembling the Flone in advance and recorded the process in a series of videos. We used those videos in the workshops, and they surely worked for the building/replication of the Flone. Crew members (participants) helped each other without us having to push for that. The puzzle-making seemed pretty natural to them. The videos, however, didn’t help us have deeper talks about technology, science, knowledge(s), power. It was difficult to discuss details or get their feedback. Our solution was partial, and so was the engagement with crew members.
For stage two, Stevens, a Haitian collaborator, helped us make an introductory video in Creole, which helped new members get into the process, and feel welcome (we guess). We also used google translate (the phone app). But it wasn’t enough for the needed talks, or for getting feedback or properly documenting their ideas. And in a fast paced environment of a 3 to 5 hours workshop, pausing to use a translation app wasn’t easy. GitHub (an online collaboration platform) is in English and although most our content is in both English and Spanish, not all is, so asking non-English or non-Spanish speakers, to go check/complete GitHub wasn’t feasible.
Takeaways:
Translation apps, and videos in the language of those participating weren’t enough to elicit a strong sense of cohesion, meaning and purpose during workshops. All which we think is important if we want people to knowingly and willingly put their contributions and feedback on the table. Isolated solutions were cosmetic in the absence of a comprehensive, and educated, approach to dealing with language barriers. Storytelling is needed to convey complex messages and to bond with people. We do not know how to approach this next time. Maybe a huge dose of creativity is needed. Creatives, help!
Being optimistic, we might expect collaborative platforms like Github be made available in widely spoken languages like Spanish, but maybe not so in the case of Haitian Creole or languages of other small or traditionally segregated groups/nations. What to do then? Any ideas?
2. Documentation
The problem:
Good documentation is hard to produce. By ‘good’ we mean documentation that allows anyone to reproduce what we did, and also understand what’s involved in adapting it for her own needs. But the level of details involved is huge, and it is also a permanent process. You can’t go through a workshop and not document what happened in there. And this can be tedious. It is very common to have only one, a couple or a few people taking care of the documentation, instead of a distributed group doing it. And this intersects with the language issue too, since it is easier to learn and to contribute one’s knowledge in one’s mother tongue. The question is how to move towards a more effective, collective and inclusive documentation process.
How we approached it:
We thought an essential part of an open project is to have documentation that is easy to modify, easy to access, easy to understand to all those the project is intended to reach. We used Google Docs for writing the drone assembly guides and drafting many other project documents. We tried to get all those that contributed to the project involved in documenting it, see it as essential and not feel threatened about it. One thing we did was to have a laptop always open during workshops and ask people to write down there any idea, question or comment about the hardware or the process. Lack of reliable internet connection meant sometimes they would write in a Word document, sometimes in a Google Doc, sometimes in GitHub, sometimes in a physical paper. Another strategy we tried was to dedicate the last 15 minutes of the workshop for brainstorm-like documentation and feedback. Despite most crew members contributing with ideas or notes, few got a taste of what documentation really implies, like the need to make it truly accessible to others.
Takeaways:
Having a standard documentation format, like a written document in google docs, might help participants get accustomed with getting involved. But this could also be counterproductive. A standard format might not account for cultural or background differences. Some feel more at ease with taking handwritten notes, some with writing in a computer, some with drawing, some with talking about it. We should be open to different formats of documentation; written guidelines might well be complemented or even replaced by visual or audio formats. It also seems to be important to stay vigilant and hopefully evaluate what seems to work with the most “unusual” participants (kids, elderly people, those everyone told them they “can’t”). But when having different formats, integrating them becomes an issue.
Making sure the documentation can be easily understood by everyone is key. Give the guidelines to a teen friend, to your neighbor, to crew members, and ask them to read and see what they get and what they don’t. Maybe talk to someone partially or totally blind and see what could work for him, what sort of ideas he’s got. This sort of feedback is needed.
3. Dependence on closed-source tools
The problem:
It is easier to keep using closed source tools we already know (like google docs) instead of trying to find open source tools, aligning such use to our principles for action, and adding strength to the open source story we want to tell.
How we approach it:
Our first attempt was to start using the Open Science Framework, a collaboration platform for open science projects, which seemed like a perfect fit for Vuela. Unfortunately, it didn’t work out for us. We uploaded information there, but it wasn’t useful for us to collaborate. In May 2018 Vuela was part of the Mozilla Global Sprint, and for that we created our repository on GitHub, a collaboration platform widely used by open source software developers. We found out later that GitHub itself is not open source, and it was recently acquired by Microsoft. We are still regularly using GitHub for our project, but we will probably switch to the open source alternative GitLab. We also set up an online forum using the open source software Discourse, but unfortunately most of the project communication still is channeled through Whatsapp and email (mostly Gmail).
Takeaways:
What tools to use? Unfortunately, there aren’t in place lots of good open source tools for every aspect of collaborative work and documentation. And despite us not wanting to use proprietary software, we have to admit some are pretty useful; google docs is a very efficient tool — we can’t wait for an open alternative.
Here we lists some open source tools that could be used as alternatives:
Etherpad instead of Google Docs (public etherpads by Mozilla, Wikimedia, Riseup, and others)
GitLab instead of GitHub
Jitsi instead of Skype
Riseup or ProtonMail instead of Gmail
Riot instead of WhatsApp
4. Having our own place
The problem(s):
Not having our own physical space to meet limited our options during workshops. We were lucky to find people who helped us get a place: at a neighborhood council venue and then a catholic church event room (in Chile), at the Club Social de Innovacion Balcarce, and INTA (in Argentina). But lacking a space to call our own had the downside of us not being able to, for example, enforce a code of conduct and to invite whoever we wanted. For example, certain groups have traditionally not been welcomed by the catholic church, groups we would have loved to have as collaborators (like the LGBT community).
How we approached it:
We didn’t.
Takeaways:
At the same time of this being a problem, an essential part of engaging with people you don’t live next to and are in close connection to, is to enter ‘their’ spaces and playing in there, instead of inviting them to a foreign little bubble.
Maybe a combination of venues for the workshops could be a good idea, having our own space so we could invite the ‘untouchables’ to play along with the powerful (and not so powerful), but also going to places where we get invited to and/or places that take us out of our comfort zone.
5. Access to basics
The problem:
Access to computers, to internet connection, to proper building infrastructure (with basics like toilets) is often missing in the type of urban areas where we conducted many of the workshops in 2017 and 2018. Those basics -taken for granted in so many contexts where “open science” and open science hardware are often discussed- aren’t a reality for many who need or would be eager to involve themselves in science. So, how open is what we are doing really? We are publishing the assembly guides in Haitian Creole and Spanish but that doesn’t mean they will be accessible to people that should know about them. It was frustrating to see some of our crew members being eager and willing to do more research on drones and build their own but being unable to do so because they don’t own computers, and even if they did, there is no place for them to go sit, connect, research, for free.
Because of the nature of our workshops, access to internet was key. Except in a couple of places like UFRGS in Brazil, and INIA in Uruguay, we did not have proper in-house access to the internet during workshops. In Chile that is because internet access is an expensive consumer good, impossible to afford for a small neighborhood committee. For example, someone in our crew pays the equivalent to 41 USD monthly for a wifi router to which you can connect up to 10 devices and has limited capacity. We used that router in the workshops, but many times the connection was super slow, as the telecoms do not invest in infrastructure in poorer and/or periphery neighborhoods. Needless to say, having a slow connection gets on people nerves and make things harder.
How we approach it:
Mostly we didn’t. We took our own router to some workshops, and other times we used internet from our mobile phones, which did make a difference but still wasn’t good enough as not many devices can be connected and the connection was slow.
Takeaways:
We should stress in the conversations during workshops that access to the basics is “a basic thing”, and that our fight for open science hardware should also be a fight for truly open accessibility to the basics. What does this entail? Community science centers based in every neighborhood?, based in universities? Based in both? Free internet centers in every neighborhood? Of course one size fits all solutions don’t work, but we do need to think of how to link the open science hardware community to other communities fighting for ‘the basics’.
During the workshops some of us started dreaming with community-based connectivity projects. These are basically internet networks built and managed by the same communities, not companies. After the workshops, we are more convinced these types of networks aren’t only an option in isolated or rural settings, but also in urban areas.
And for what comes with Vuela, securing better internet connection is very important and if there is no good connection then it is important to openly and purposely talk about it with crew members. To not only feel its absence, but to discuss how come internet isn’t a ubiquitous thing, as we are often told.
6. Gender
The problem:
You can imagine. We had very-very few women attending the workshops, and nobody defined as non-binary. In 2018, in the Argentina workshops we sometimes had only one woman in groups of 5 to 10 people, and many times none at all. In Chile, we often had only one or two women in groups of 10–12 total. During the PROCISUR funded workshops we observed there was better female representation when those in charge of the group were females.
How we approached it:
We did little. In Chile in 2017 we always had around 20% of women in our workshops, often invited by one single lady (quite a leader herself) who came to almost all workshops. She didn’t attend the workshops in 2018 and nor did we had her friends or acquaintances attending. On the invitation flyers we used feminine nouns, “invitadas” along with “invitados”, we also asked male crew members to bring their friends, sisters, wife, daughters, to which many of them replied things like “they wouldn’t do so… for what”, “no, they wouldn’t want to come”, or “they are busy”. In some cases, we couldn’t dig deeper into the reasons or try to convince them because of the language barriers. Other times, when the language wasn’t a barrier, we just did nothing to try to convince participants to bring females to the workshops; we did not actively engage in those conversations.
During the OVLI testing workshops, we talked to the people in charge of recruiting participants and asked them to have as many women as possible. Only in one of the workshops half the people were female, in the others the majority were male. We do not know however whether they tried to comply with the request by bringing just any woman available (got that impression in one workshop), or whether they truly looked for those who were interested in the workshop.
Takeaways:
No doubt we could have been more creative and done more. Even something simple as starting a short conversation about the issue with participants. The fact is that a more comprehensive strategy is needed for future activities, even if it is a simple strategy. We will dedicate the required time to this next time. We want Vuela workshops to be safe and feminist environments.
We also need to make sure we know how to approach things when males or females say things like: “be careful, a woman got the controls!” which is something we heard more than once in workshops. We used the AORTA facilitation guide, but reading a guide is not enough to know how to tackle issues like this in person. Therefore, we might need proper feminist facilitation training. Do you know any good option? Let us know!
There was one episode in which our code of conduct was broken, although it did not happen during the workshops but after, at a goodbye lunch. So maybe it can not be said it was broken. Maybe it means the code worked, and this person felt he had to wait until the end of the workshop to say what he said. We still need to reflect on the incident and on the way we presented the code of conduct at the beginning of the workshops. We did not give space for discussing aspects or details of the code, and maybe in contexts in which people are somehow obliged to be present, that digesting time is needed.
7. Mixing up apples and oranges
The problem:
Have you eaten apple and orange together? Grated apple with orange juice, delicious. Well, we didn’t manage to offer the equivalent to that, in drone-workshop terms, meaning the act of mixing people with very different backgrounds. We wanted to have researchers or academics working side by side with people from radically different backgrounds, people with no background on technology, science or traditional education. In 2017 we managed to do so in the last workshop of the year. And in 2018, we only managed that mix in one single workshop. We did have academics and non-academics participating, but in different workshops, at different venues. In a way, we ran segregated activities. Researchers didn’t want to attend the workshops ‘in the city’ while ‘non-researchers’ did not feel like going all the way to the research place -understandably-, which in Argentina was out of the city, with no easy transport.
How we approached it:
We decided that first and foremost we wanted people to attend and keep attending the workshops and work on the needed changes to the drone design, contributing their knowledge. We also stressed, in every workshop, that other workshops were being conducted with different people, and that all inputs were equally valuable. For that we first started using the ‘issues’ feature in GitHub (a sort of interactive to-do list), to keep track of what was being done (and especially who did it), and try to give participants in different locations a way to interact.
Takeaways:
There are definitely ways to enthuse people to join “different people” in workshops like ours. What is needed is strategy and to create strategy we need time to test and retest, trying different ways to connect with communities or groups, and this means money. For example, we could have offered a free ride for people from the city to go to INTA or offer researchers to take all them together to the Club Social in the city, or hire local people to be our local-connectors, and end some workshops with food and beverages so people could mingle and party together, which for sure helps create bonds and break barriers.
8. Facilitation
The problem:
Facilitating workshops like these is underrated. In general, nobody talks about how important it is to facilitate. People talk about teaching, chairing or presenting, but not facilitating. The attitudes towards learning most people bring into the workshops speak to us of an educational system which mostly encourages passiveness. And these aren’t easy barriers to debunk. The most common expression heard at the beginning of the workshops was: “oh I can’t”, “oh, I don’t know”, “I’m not good at it”.
How we approached it:
In a way, the whole project itself is an attempt to debunk these notions of how learning takes place and who can learn and who cannot, and who teaches. We avoided using blackboards, powerpoint, and almost anything that would remind people of a typical classroom. We used a facilitation guide, but it is not specific for workshops like ours, so we just took the general advice. Still, reading a guide and actually implementing what it says are not the same. We therefore made the conscious effort to learn what seemed to be working from one workshop to the next. Our way of engaging people in the tasks changed quite a bit from workshop 1 to workshop 40.
Some basic things we tried:
- to stand if people stand, sit if people sit, trying not to resemble a typical classroom,
- to ask people to move around the tables instead of sitting in the same spot all the time,
- to push people to ‘explore’, to open boxes and bags containing parts and components and think what they could be useful for, instead of following a set of instructions
- emphasize we (the facilitators) are not teachers or professors but peers. This last one was hard, there are very entrenched attitudes to what is supposed to happen inside a learning space: some people who “know” stuff and people who don’t.
Overall, our latest iterated approach, that we used in the latest OVLI-testing workshops, is to take the “find-out yourself” tactic to the extreme: for every piece of wood or electronic component participants take out of the box, we ask them what is it for, and give them a large amount of time to try to find out among themselves, create hypotheses, contradict each other, laugh, just fantasize… Do like a collective progressive puzzle making, trying us not to touch the parts too much, letting the rest touch everything as much as possible.
Takeaways:
Trying out new engagement techniques during workshops requires us to be good at facilitating. Systematizing our methods feels like a pressing need, to more clearly see what works best, what could be replicated and what not from workshop to workshop or setting to setting. But if we fail at the facilitation front, then it’ll be hard to assess whether certain techniques don’t work because we are bad facilitators, or because of something else. Being a good facilitator might be a priority skill to have in order to achieve the impact we want to achieve.
9. Narratives
The problem:
Mentioned earlier, the narratives of science, of knowledge creation, of instruments and who makes them are so strong and deep seated that unless we propose new stories, compelling, relatable, we won’t be able to push for open science the way we imagine it. In our workshops, people wouldn’t normally go grab stuff and start trying out things… unless we insisted and insisted, a lot. Most of them didn’t even felt confident in opening up the boxes and bags. The kids from Club Social, those you’d expect to be more flexible or adaptable, keep calling us “professor” despite us begging them not to do so.
How we approached it:
We expected the idea that everyone can be part of the drone creation process would be better shown through the actions and results of the workshops. Whether crew members saw it that way or not is something we still need to find out.
Takeaways:
As with other barriers, we were not vocal enough in trying to overcome them. We think next time we should be more vocal about the structural things we aim to help change: how we all learn, why collaboration is key, knowledge production, science… but how? Maybe the use of images, pictures or videos could be part of the strategy?
10. Small funding means little everything
The problem:
Funding, that says it all. We managed to fund our activities in 2017 and 2018, but not to fund -properly- our time (we got trips and accommodation covered by the funders). Funding for salaries is essential for projects to be sustainable and reach their potential. If there isn’t money to pay salaries, those who end up involved are the ‘usual suspects’, those in academia that already have a salary that pays for the engaging in these projects or those who have the type of financial resources that allow them to donate their time. We need the unusual suspects to work on projects like this too, and they (we) need salaries.
How we approached it:
We didn’t.
Takeaways:
One process that often get sidelined is convening, which might feel secondary in the rush to get things done but it is actually essential. Convening the right mix of people, and as all the other things, takes time to plan and money to execute.
Look for bigger and/or better funding. Be explicit and vocal about it.
Getting funding that includes salaries is harder or even impossible when you are not a legally registered organization. We might have to consider becoming one. Or not. What do you think?
To be continued…
Missing here is a detailed reflection of the methodological decisions we made along the way. That requires another post/report in itself. And probably some other things we learned are also missing.
We are trying to take all of this into account as we plan our future actions.
In the meantime, we keep flying…
