I’ve been relatively obsessed as of late with cross-platform integrations in Trello and, more recently, Rocketchat (a free and open source Slack alternative) for coordinating the many tasks involved in the day-to-day affairs of my two main project-babies: Omni Commons and Sudo Mesh. There comes a point where it all became too much to juggle – and despite my appreciation for decentralization, I need a high-level overview – a map. A map with links. And media attachments. Also it needs to have a pretty UI. I turned to Trello, and then I started playing with the possibilities.
I will now proceed to attempt something of an instructable for maximizing the utility of webhooks in project management platforms:
Step 1: Create a Team
A Team in Trello consists of Members and Boards. Boards might be differentiated by sub-projects, departments, working groups, or committees – or, if your team’s not quite so structured, perhaps simply topic areas. Smaller teams or those who prefer to have all of their tasks in one place might choose to use only one board for all tasks.
For example, Sudo Mesh is a Team consisting of the following Boards: Communications, Events, Node Mounts, Github Repos, and Internal Logistics/Bureaucracy/Brainstorms. While some members are subscribed to all Boards, many are subscribed only to one or two areas of focus.
Step 2: Design your Boards
Each Board is made up of Lists – a simple, standard method is to create Lists for ‘To Do’, ‘Doing’, and ‘Done’ – Kanban style or whatever it’s called. Tasks are added as Cards to the ‘To Do’ List, moved to ‘Doing’ when a member begins working on the task, and then moved to ‘Done’ upon completion. Here’s an example from Omni’s Bookkeeping Board:
However, there are as many ways to organize this as you can imagine. It might be best to have a List or two consisting of static assets, as seen in the ‘Internal Logistics/Bureaucracy/Brainstorms’ Board below. This Board is something of a catch-all for important documents, overall project milestones, and random ideas for future features. In essence, it’s something of a merge of a strategic plan, a business plan, and organizational assets:
Another example of a combination of task management and shared documentation is the ‘People’s Open Events’ Board below:
I tend to make the first List the main ‘To Do’ List. Members can join a Card indicating they’re taking on the task, and any Team Member can comment or add attachments (including links) to any Card. The ‘Workshop Assets’ List contains the Cards ‘Handouts’, ‘Flyers’, ‘Presentations’, and ‘Swag’. Each Card has several attachments to documents, images, video recordings and slideshows from past presentations – simultaneously a resource of materials we can reuse for the next workshop as well as inspiration for future workshops.
As we learn about conferences and other events we may want to participate in or present at, they can be added as cards to the ‘Upcoming Events’ List. Once an event has passed, Members can add video recordings, presentations, handouts and signup sheets to it’s Card, which gets moved to the ‘Past Events’ List. All events are dated using the ‘Due Date’ Card option, and a full calendar can be viewed by clicking the Calendar link in the top right – a Trello ‘Power-Up’ feature available to paying users or those given free Power-Ups after an invited member makes a new Trello account. Which brings us to…
Step 3: Create Card Flows and Integrations
This is the ‘secret sauce’ of Trello that I’ve yet to find as powerful an alternative to among the various open source options currently available. If you max out on Power-Ups, you can always use Zapier for further integrations (free accounts allow for up to 5 integrations). Between Trello’s Power-Ups and Integrations and Zapier, there’s seemingly no end to the number of possible integrations with other platforms and tools used for team collaboration and communication.
Using the Internal Logistics/Brainstorms/Bureaucracy Board above as an example, I set up the following integrations:
* The Calendar Power-Up, which attaches cards with due dates to a calendar view which is then synchronized with our team’s Google Calendar;
* The Google Drive Power-Up, which enables members to directly attach Google Drive files or folders to a Card;
* The Github Power-Up, which enables members to attach Github branches, commits, issues and pull requests to Cards.
Trello Integrations make it easy to create hubs for the many ways we communicate online – from Github to Mailchimp, press inquiries to community outreach, email to social media accounts. Here’s our Communications Board:
In this Board, I’ve created the following integrations:
* The Twitter-Trello Zapier integration (aka ‘zap’) automatically adds any public @ mention of our twitter accounts (@sudomesh) as a Card to the List ‘Social Media’;
* The Mailchimp Power-Up allows us to attach our Mailchimp newsletters to Cards, providing an overview of how many people were reached, who opened and how many clicked an internal link;
* The Github-Trello zap is used here to track issues and bugs submitted to our main code repositories;
* The Facebook-Trello zap adds posts and interactions with our Facebook page to the ‘Social Media’ List;
* The Gmail-Trello zap automatically adds any email I label ‘Mesh Inquiry’ to the ‘Email Inquiries’ list;
* The Calendar Power-Up gives our team a sense of how on top of our communications we are, and a historical timeline of public interest, press coverage, code development, and community outreach efforts.
Not on this Board but related: using a Google Form-to-Trello zap, any request to host a node sent though our Google Form is added to the Node Mounts Board under the List ‘Needs Followup’ as well as to a Google Spreadsheet tab. That spreadsheet has another tab for manually-input additions from team members, which are also added to the ‘Needs Followup’ Trello List using a Google Sheets-to-Trello zap.
Now, I’m not one to enthusiastically plug corporate, proprietary software tools – I just used what I knew was possible to create a high-level overview of the overwhelming array of code repos, shared etherpad-lite notepads, Google Docs, emails, events, requests, social media accounts, and other assorted sundry communication mediums, tasks and sub-projects that Sudo Mesh encompasses. Now I can see everything in one place, which is great, but how to get the rest of the team on-board?
Step 4: Integrate into Team Collaboration Practices
This can be done in a variety of ways, but one thing is certain: it’s always challenging to get people to use a new digital tool, especially when they’re not being paid to do so. Some strategies and tips I’ve picked up from the past failure of garnering participation in Omni’s Trello Boards and the current comparative success with Sudo Mesh:
Delegate roles and responsibilities.
In the beginning, this may entail the creator of the Trello Team assigning members to Cards. As members gain more familiarity with the platform, some will take to it and may well become stewards of a particular Board – encourage this! Decentralizing the role of ‘Project Manager’ leads to a sense of shared ownership, improves leadership skills and autonomy, and takes the burden off any individuals who may have had too much on their plate to do any one thing particularly well.
Use your system as a guide for structuring meetings and assigning action items.
We recently restructured Sudo Mesh’s weekly meeting format, and I took it as an opportunity to structure updates around our recently-created Trello boards. Here’s our current meeting format, where you can see our Trello Boards linked as a reference in the various project areas we check in on at each meeting. Action items that folks take on at meetings can then be added as Trello cards with assigned members – which anyone can add, thereby reducing the role of an individual top-down “manager” and augmenting that of “collaborator” in the mutual aid process of building the dream.
Set clear goals and develop group processes.
Recently, Sudo Mesh had a strategic planning session, where we discussed our short-term and long-term goals and organizational structures. These goals were then copied to the Trello boards, spread among the various categories of Boards and Lists. From there, we can drill down to the independent tasks needed to accomplish each goal, assigning them due dates and team members. I’m a big fan of abstracting each goal and then refining it in Checklists, of which you can add multiple to each card -you can even save a Checklist and reuse it in future Cards. I created an ‘Outreach Checklist’ in the Events Board so that we don’t forget to send our event flyer to specific local news outlets and mailing lists. Another team member created an ‘Outreach Checklist’ in the Node Mounts Board with a list of questions we should be asking every new node owner before we set off to climb their roof. There’s something inherently, deliciously satisfying in the act of making a checklist and then crossing off action items, refined over time until each recurring task becomes a well-developed, well-documented and efficient group process.
Design for big-picture clarity and historical reference.
As the archive of Trello cards grows, team members have a qualitative timeline and a collective journal of the tangible contributions, conversations, and achievements they’ve made together. It gives the project a sense of coherent narrative that surpasses
Of course, such a narrative is much more compelling, engaging, and authentic/validifiable when it’s: a) dynamic, adaptive and hackable; and b) transparently, openly, and publicly documented and accessible (enter FOSS)…
Step 5: Iterate!
As your project evolves, so will your project management structure. Don’t be afraid to archive old Boards or merge Boards, but I would advise against making too many Boards – recreating the problem of ‘too many things to keep track of’. Most importantly, be open to the very real possibility that this just isn’t the right modality for organizing this project. My experience arises out of an embeddedness in a culture that tends toward being digital tech-heavy, valuing productivity and literacy over communality and orality. Perhaps this is why such a structure, despite multiple attempts, could never thrive among the large and diverse community that makes up Omni Commons – moreso due to the fact that most everyone is there to contribute to their own collective projects. What works best to organize and motivate Omni volunteers are: work parties that happen in the spirit of participatory camaraderie; blackboards for denoting tasks and issues; and flyers for announcing events, campaigns and needs/offers.
But, I digress: back to iteration. Last month, a teammate deployed an instance of Rocket.Chat on our peoplesopen.net server. Up until then, communications had become increasingly varied and at times extraordinarily frustrating. We’d already had two mailing lists, an IRC channel, a wiki, a blog and a Github organization when we added the spokes that broke the mesh’s web: multiple Signal groups, their continual notifications haunting one’s periphery of attention at any given moment. On top of this newly-added, geographically distanciated layer, we were organizing quarterly workshops and again meeting at least twice a week – frequently more often to work on focused sub-projects alone or in small groups.
If we could just wean ourselves off of the other platforms*, Rocket.Chat satisfies many of our varying communication needs:
Provides ability for mobile, private and secure 1-on-1 or group messaging, a la Signal;
Preserves chatroom history, a la IRC – and integrates with existing IRC channels;
Enables file-sharing, search, archival, and contacts management, a la Gmail – and integrates with email;
Is entirely self-hosted, free and open source software.
Has hella *integrations!* with *Trello!* and IRC, email, Github… more of a Slack alternative. I’ve already set Github issues to announce to the #bugs channel and updates to the Communications Trello board to post to #comms…
* the website, wiki and code repositories would be merged with rocketchat in my utopian future
2016 was a grueling year – I dreaded the end of each and every month, which meant we’d be scrambling for the funds to pay Omni’s $15K rent, with additional expenses sometimes adding up to nearly $20K. We got by (barely) thanks to the faith and generosity of comrades with savings, who lent a total of $70K over the course of the year at 0% interest.
We’d courted a potential donor-lender at the beginning of the year, but at the last moment they got skittish and called off the deal. So, we began putting together a commercial real estate loan application – which entailed getting our books in order. Probably I should have tallied the hours I put into pouring over every transaction ever made, scouring the web for nonprofit accounting tutorials, mastering the ins and outs of Quickbooks Online, and refining our chart of accounts – it was certainly in the triple digits, I can tell you that much!
Finally, in November, when we were certain we’d exhausted our collective minds, energy, and bank accounts, we received word that a potential anonymous benefactor – who’d initially offered to donate a million dollars if we could finance the other million – had agreed to lend us the other million at market rate. We were ecstatic! It was going to work!
Of course, as expected, it wasn’t quite that easy. Since the donor-lender had previously donated to our nonprofit in excess of $5,000, their donation would not be considered charitable by the IRS – meaning we would certainly be reclassified as a private foundation, subject to potential 200% excise taxes on any prior transactions deemed “self-dealing,” and other associated complexities I won’t bore you with here.
Our solution? Sudo Room, which had just acquired its own 501(c)3 status, received the donation instead. Sudo’s Board of Directors resigned, with the exception of myself as the sole Director on both Omni’s and Sudo’s boards, and I nominated Omni Oakland Commons’ (OOC) current Directors to Sudo’s board. That Board then passed resolutions changing Sudo’s name to Omni Commons, amending the Bylaws to match OOC’s, and adopting Sudo Room as a fiscally-sponsored project of its former self.
The whole process, including transferring all existing promissory notes, subleases, and fiscal sponsorship agreements to Omni Commons (new-omni), as well as the building purchase documents, consisted of more than 60 contracts and agreements created and signed by over 40 entities in the span of a month. With the excellent guidance of our lawyer, Jesse Palmer, the good-faith collaboration of our community, a lot of hard work and a whole lotta luck, Omni Commons became the owner of 4799 Shattuck on December 7th, 2016.
As for my own sanity and self-development, for better or worse I now know a hell of a lot about nonprofit accounting, promissory notes, commercial real estate loan applications, and building purchase mortgages. Now to help a hundred more Omnis bloom!
On December 2nd, as soon as the purchase of the Omni Commons was finalized (!!!), I packed up my car and took off for the Standing Rock Sioux reservation (located about 1600 miles northwest) with a comrade to join the fight against the Dakota Access Pipeline. Over the previous two months, I’d been looped into the Tech/Comms team on the ground via another comrade, Lisha Sterling from Geeks Without Bounds, and had been advising on building out a local area or mesh network to help with connectivity and communications issues on the ground.
We arrived during one of the more tumultuous times at camp, as the population had spiked to over 12,000 people – many of them hugely unprepared and underequipped for the arctic conditions of North Dakota in December. It was an intense experience personally for many in our community – halfway through our trek across the country, friends and relatives reached out with horrific news: over 30 people, most of them young artists and activists embedded in the social fabric of our lives in Oakland, had perished in the tragic Ghostship warehouse fire that weekend.
So we arrived, shaken and heartbroken and more than a little sick of each other’s company to boot. The final miles of our journey into camp were a slow crawl behind hundreds upon others who’d come in solidarity – but just as many hundreds of vehicles headed out of camp. Apparently, the judge had denied the easement that would enable DAPL to continue constructing the pipeline that month, and approximately half the camp concluded this was a victory. We arrived to a bewildering scene: reuniting with brokenhearted friends from Oakland, firework celebrations and partying over a perceived victory we knew was short-sighted, and the first dangerously-low temperature dip of the season: -10°F (-23°C). Over 30 people that night were reported by Medical as hypothermic.
I was so incredibly grateful when Lisha greeted me with news that the Tech Tent had just been outfitted with a stovepipe, and that bunkbed cots were on the way. After spending my first day getting oriented and making the Tech Tent habitable, I recorded my first livestream:
That week, given the timing, was largely spent orienting myself, trying to understand what the fuck was going on with continual actual threats as well as false alarms triggered by the State, constantly-shifting internal community power dynamics, and multiple small emergencies daily (such as bringing a generator to a camp whose horse trough had frozen over). Lisha was horrifically sick with a bronchial infection (as were many at camp, thanks to a killer combo of cold, smoke, and stress), and the majority of the tech crew had just left. I found myself faced with one of the more challenging set of circumstances I’ve experienced in my life: rapidly adapting to extreme and unfamiliar conditions whilst balancing the need to listen and deeply understand a sacred space and struggle with the call for active leadership on the technical and communications front.
It was bitterly ironic to be burning wood and propane when we had an abundance of resources for building a sustainable energy grid – then again, these were critical environmental and psychological conditions unlike most anyone has ever known. At times, it was hard to think about anything other than how to warm one’s fingertips. Nevertheless, I was staying in a comparably toasty tent full of solar panels, wind turbines, and radio equipment – hella privileged, I had to admit, as I hauled hay bales generously donated from the back of the Wellbeing Tent to provide a layer of insulation around the Tech Tent. We had a stockpile of much-needed gear, but not much in the way of a crew capable of deploying it. So, I set out to build a crew – focusing first and foremost on power.
As is often the case in communities bound together by a unifying cause in the face of a powerful enemy, it didn’t take long to find the others. By the end of the week, we had a skeleton crew of smart, capable techies making the Tech Tent one of their home bases, had inventoried and tested our equipment, and had begun to deploy power crews to most-needed locations whilst collating a map and a plan for the rest of the camp.
A week or so into my arrival, the main public hotspot (a Ubiquiti NanoStation M5 running on stock firmware with a point-to-point connection to the Wellbeing Tent at the base of Media Hill) disappeared from its semi-prominent location at the dome in what was clearly an act of sabotage:
Luckily, I’d brought a few routers (MyNet N600s) already pre-flashed with the sudomesh firmware. I set one up in the Wellbeing Tent with a direct ethernet cable connection to the directional antenna receiving internets from the hill, and another one inside the dome. With a range of ~100 meters, the two nodes were able to see each other and mesh easily. Both tents now hosted open peoplesopen.net hotspots in addition to the private ssid at the Wellbeing Tent, the password for which was distributed to indigenous leadership as well as the tech and media crews.
A few days later, I met a comrade from Sacred Stone who shared some footage of sabotage they’d uncovered at the other end of camp – a perfect-condition snowplow destroyed by way of removing a critical part; additionally, several power lines and insulated water pipes destroyed. But the sabotage was merely the tip of the iceberg of psychological warfare waged against the Water Protectors – from the fire hoses in sub-zero temperatures to the nonstop, creepy trolling of all of our walkie-talkie channels, there was no possibility of escape from it.
I wasn’t at Standing Rock long – a mere two weeks, buffeted by the Omni building purchase into December and a long-planned trip to Africa with my partner’s family at the end of the month – but I learned more in those two weeks than I can even begin to articulate in this post. The importance of trust (AND paranoia) in liminal spaces of contention, maintaining internal peace in the face of at-times violent chaos, organizing with humans who’ve reached their physical and psychological limits, carrying on and doing what needs to be done when all hope seems lost, and ultimately, finding grounding and humility in serving the indigenous leadership protecting and honoring Maka Ina – Earth Mother.
My final livestream, sounding much hoarser and wearier:
This summer marked the 8th annual Battle of the Mesh in beautiful Maribor, Slovenia at the foot of the Swiss alps. Each year, folks from around the world who work on open source mesh networking protocols (schemes for routing packets across a network) and community wireless networks converge to deploy a testbed mesh network, running different protocols on top of it and analyzing which of them perform the best.
Mount Pohorje in Maribor, Slovenia, site of BattleMesh v8!
This year, the conference agenda also included a wider variety of topics, from decentralized and secure file systems and applications to political discussions about the future of open hardware and firmware in the face of imminent federal regulatory lockdown measures.
The first day was largely spent socializing and setting up the topology of the network:
Topology of the testbed network built at BattleMesh v8
Five actively maintained and deployed routing protocols were tested over the course of the week:
* Babel, a distance-vector routing protocol for IPv6 and IPv4 largely developed by Juliusz Chroboczek in France;
* Batman-adv, an implementation of BATMAN [Better Approach to Mobile Ad-hoc Networking], spearheaded by the Germany-based Freifunk community;
* BMX7, an experimental protocol designed to bridge Layer 2 and Layer 3 routing;
* OLSRd1, short for ‘Optimized Link State Routing’ and widely utilized in many of community networks due to its stability, scalability and active development community,
* OLSRd2, a new iteration of OLSR designed to be more modular and flexible, published by the IETF in 2014.
Day 2 started out rather chaotically, as a dozen wireless hackers attempted to fix the internet they’d borked. The afternoon’s talks featured an excellent presentation by Julius, the lead developer of Babel, entitled ‘babel does not care.’ You can watch the talk (with accompanying slides) here. Julius’ talk was followed by a presentation of GNUnet, a free-as-in-freedom alternative and privacy-conscious network for peer-to-peer filesharing, VOIP communication, and peer discovery that works over a variety of transport mechanisms. Watch the full talk with slides here. Next, Elektra of Freifunk gave a presentation on the current state of TV whitespace spectrum and the potential future applications of UHF. I highly recommend watching the talk, as Elektra concludes with a stirring call-to-action for the community to engage with the political struggle over spectrum allocation, one unfairly slanted toward powerful telecommunications companies over free and open community network usages.
Day 3 kicked off with a presentation by Mathieu Boutier on source-specific routing in Babel [Video]. Next came a presentation on cjdns, a distributed and end-to-end encrypted p2p IPv6 meshnet project better known as Hyperboria. They have just begun collaborating with a fascinating project called IPFS, the Interplanetary File System, which combines ideas from Git, Bittorrent, and the web to enable such applications as peer-to-peer filesharing through creating a distributed content cache accessed through a hashed URL. Check out their talk, which appropriately followed the cjdns presentation. Folks from Battlemesh are using IPFS to store media content uploaded by conference participants!
An easy-to-assemble, open hardware plasma cutter from Irnas.
We celebrated the mid-point of the conference by spending the afternoon and evening in Maribor, first with a tour of KreatorLab. KreatorLab is home to a bevy of inspiring open hardware projects, including a plasma cutter, a 3D printer, and Koruza, Musti’s brainchild enabling gigabit wireless optical links.
After our visit to KreatorLab, we headed over to the GT22, a self-described “transdisciplinary laboratory in real space with transnational guerilla art school institutes” hosting space for theater rehearsals, a radical library, a photography museum, an indoor skating ramp and a party space populated by a VJ projection screen and a DJ booth. While the DJ played dance music, our true-to-form hackers proceeded to gather outside and along the walls not dancing 🙂
Thursday, Day 4 of the conference, began with a presentation of Cake (Comprehensive Queue Management Made Easy), a project that works to make wifi faster by reducing network latency. The following presentation by Dave Taht provided an excellent overview of the current insecurities in Internet of Things devices outlined across 11 layers of the network stack, culminating in a rousing call-to-action for hackers to build more and better open hardware. I highly recommend watching this talk!
Dave’s talk was a fitting antecedent to the subsequent presentation and discussion of the FCC’s recent proposal to lock down wireless routers by requiring vendors to “ensure that only properly authenticated software is loaded and operating the device.” This has huge implications for community networks in the US, with similar rules being discussed for the EU and Canada. After a heavily animated discussion, folks continued to discuss the issue over lunch, with many inspired by Dave’s talk to create our own hacker-friendly hardware down to the chipset level. We created a mailing list to collaboratively compose letters to the FCC, the comment period for which has recently been extended to October 9th and is open to everyone.
Unfortunately, I missed the entirety of Thursday afternoon’s talks as I literally sat in the same spot at our lunch table conversing with new friends into the evening.
Friday kicked off with a presentation from Demos to consolidate and test various decentralized applications with the aim of supporting a more decentralized web. She was followed by Nemesis presenting, NetJSON and Nodeshot, projects working to build node databases for network monitoring and administration. After lunch, Paige gave an impressive presentation on MaidSafe, a secure and decentralized storage and communications platform.
On the last day, a few of us set up a video camera and did short interviews with representatives from as many community wireless networks as we could gather. The focus of the interviews was to explore the various motivations and unique challenges faced by a diversity of community networks, with the aim to inspire and guide the development of many more to come. Watch this blog for updates once the videos have been edited and posted to the web!
So… which protocol won?
Given the complexity and variety of tests and analytics, the ‘winner’ is difficult to determine. Check out the beautiful (and nearly complete!) documentation, including detailed graphs and links to git repos of the software used to test the network here.
Please drop me a line at jenny [at] sudomesh [dot] org if you’d like to help plan for the very first ‘BattleMesh West’ at the Omni Commons next year!
Months of many hands working to launch our IndieGoGo crowdfunding campaign finally paid off, and we ended our campaign with over $41,000 raised, plus $40K in direct large donations. Thanks so much to the 569 people who contributed to the campaign, and everyone who shared it with their communities!
Check out the amazing video tour of the space, directed by Omni’s own Optik Allusions and with no small amount of credit to over two dozen community members:
This initial capitol campaign funding will be used toward necessary building improvements to get the space up to code and ready for hosting public events. If you missed the opportunity to support the project during this campaign, we’d greatly appreciate any contributions toward our next campaign: buying the building!
Last Saturday marked the final day of the Bay Area Public School’s weeklong Summer School, the theme of which was Information. We started the day with a Cryptoparty – hands-on workshops to assist folks in generating key signatures, using encrypted and off-the-record chat, and other tools such as Tor and Redphone – this went really well, with lots of folks leaving having learned new skills or solved a particular problem, and all culminated in a delightfully geeky key-signing party.
There were a bunch of great talks:
* My housemate, Craig Rouskey, gave an amazing presentations on his citizen science project to eradicate gonorrhea using phage therapy.
* Marc Juul and I presented on our project to build a mesh network in Oakland!
* The lovable Danny O’Brien spoke about the Electronic Frontier Foundation’s work in fighting for digital civil liberties and why privacy and digital security are important.
The day culminated in a panel with Moxie Marlinspike (of Whisper Systems), Danny, Bill from the EFF, Marc and myself, with the attendees participating in a Q&A.
THEN WE PARTIED. IT WAS AWESOME.
Notes and link to the livestream (mad props to JC!) are here: https://sudoroom.org/wiki/Cryptoparty/2013/August
We’re having the first of what will become monthly digital security workshops at Sudo Room this month. I’m excited to co-facilitate with some hella smart friends and learn along the way. Hoping to increase digital literacy through raising awareness of basic digital security hygiene.
Here’s some of the topics we’ll cover through hands-on workshopping:
* Why digital security is important
* Email encryption and GPG key-signing
* Mobile phone security
* Hard drive encryption
* Anonymous web browsing
* Network security
As we develop our workshopping skills, we’d like to tailor future Cryptoparties to various at-risk communities such as journalists and activists.
Link to the first event is here: https://sudoroom.org/events/digital-security-workshop/
Hyperlocalism seeks to bridge the physical/digital divide by focusing on the use of information to create technology tools and media oriented around a well-defined area and inspired by the needs of local residents. Maps and mesh networks are tools that can be particularly leveraged to enable hyperlocal connectivity and information flow; I’ll briefly unpack the latter (mesh) and then demonstrate the possibilities for hyperlocal mapping.
510pen as conceptualized by Mark Burdett is based on the principles of the Open Wireless Movement: that by sharing our wifi with our neighbors, we contribute to increasing access to the internet while simultaneously creating more positive relationships with our local communities. This premise is clearly the most obvious benefit of mesh networking and is enthusiastically supported by the folks I’ve been talking with in Oakland, who see the lack of widespread internet access in their neighborhoods as a very present and real issue.
Then there is the application layer – which is the level at which TidePools is working to create software for hyperlocal neighborhood mapping. Beyond internet access, a resilient communications network endeavors to create point-to-point networks that mesh the barriers between physical and virtual space. What kinds of data and landmarks define the available resources and value of a physical community?
It might look something like this:
…in which the skills and resources of your neighbors are made visible and available to others on the local network.
Or perhaps like this, visualizing the history of a neighborhood through a timeline-based photographic montage:
Alternatively, we could use hyperlocal mapping to depict a more realistic sense of the cultural characteristics of various neighborhoods, rather than the oft-arbitrary borders drawn by state governments:
As I continue interviewing and chatting with folks about things they’d love to see on local maps, a few themes have emerged:
Environmental activists seeking to visualize pollution data, park locations, local wildlife, etc;
Unemployed and homeless folks seeking to map out resources such as public computers, food kitchens, excellent dumpsters for food foraging, and crisis centers for various demographics.
Long-term residents wishing to map out and connect local businesses and organizations in their neighborhoods.
Community organizers interested in mapping their community to strengthen awareness of existing resources and publicly accessible spaces.
Hackers and techies interested in creating decentralized networks and alternative telecommunications (eg; mesh networks, low-bandwidth software radios, etc;) – which necessarily requires mapping line-of-sight on rooftops and potential barriers to connectivity (such as raised highways)
Open government folks mapping open civic data such as crime, foreclosed / blighted properties, city legislative initiatives, and historical information.
Here are some projects I’ve been working on with some other hard-working, socially-conscious people that are tackling these needs:
Open Oakland – Volunteers mapping out open civic data in Oakland.
OpenOakland Digital Divide – Mapping out existing Oakland efforts addressing the issue of access to technology.
Oakland Wiki – A site all about Oakland, with over 2,000 articles written by community members.
Mycelia – A decentralized database I’m working on with my partner for mapping tools/inventory, skills, and projects between and among hackerspaces, intentional communities, and other self-organizing spaces.
I welcome and encourage further suggestions and use cases in the comments below!
Among technologists, for whom information and communication flow at hyper-speed and social bonds are increasingly interest-based, developing relationships with people and communities outside of your comfort zone of easy compatibility can feel frustratingly slow. The world of software development does not typically attend to the kind of bottom-up, community-based research process I’m accustomed to as an anthropologist – rather, rapid iteration is prized over emergent design and humans (who have a tendency to wield tools in unexpected and surprising ways) are reconfigured as ‘users’ of software that provides a ‘service.’ What follows is an attempt to articulate the process of doing anthropological research for developing technological tools, in the hopes of inspiring technologists to rethink the process of software development in a more human, culturally accountable manner.
Ethnographic research is the art and science of becoming attuned to the cadence of a culture. Largely, this entails the anthropologist’s direct engagement in a cultural milieu, the everyday observations of which are recorded as field notes. Field notes based on the anthropologist’s observations are accompanied by semi-structured interviews (typically recorded, transcribed, and coded) and occasionally surveys to incorporate the variety of roles, activities and perspectives that make up the cultural phenomena under study. An ethnography tells the story of a cultural group – incorporating field notes, interviews, historical research and critical analysis – and is the product of field research that relies on participant-observation as the principal methodological approach. Recent developments in the field of anthropology explore and experiment with new techniques for writing the ‘other’ that often entail treating the self as an other, first and foremost. Reflexivity is crucial for engaging in critical thinking about one’s own role and bias in cultivating cross-cultural understanding.
Multiple methods of analysis are employed in order to understand the complex dynamics of building technological tools for communities from the ground up. Semi-structured interviews are a primary source of the data and information gathered in the process of building tools responsive to community needs. Personal interviews allow community members to voice their opinions and share their biographies in a safe space of confidentiality and empathic listening, while group interviews encourage collaborative storytelling about the community’s origins and history, present issues and projects, and reveal collective visions and goals (as well as anxieties and fears). Focused discussions with community members are also a primary planning and implementation space, including sit-down brainstorming sessions aimed at raising issues and needs that could be addressed by the project.
Of further relevance is what’s known as Community-Based Participatory Action Research. Community-based participatory action research is a methodology that reorients authority horizontally. That is to say, the final product of community-based research is designed to facilitate alliances between local organizations that have vested interests in the community under study, rather than research designed to fulfill an institutional, governmental or corporate agenda. As such, community-based research tends to blend academic and activist agendas, ultimately producing something of value to the research “subjects” that is at once collaborative and politicized.
Always a fan of mixed methods, I’ve been working with the Open Oakland Digital Divide group to reach out to organizations that are already addressing access to technology in Oakland. Rather than reinventing the wheel, we thought it prudent to endeavor toward creating a hub of existing efforts by researching and documenting them on OaklandWiki. Providing such a service ideally demonstrates to the groups we’re reaching out to that we respect and appreciate the work they’ve been doing, enabling us to more effectively request their time for visiting and asking questions about what they need that we could potentially provide. It furthermore creates an opportunity for us to serve as bridges, building a coalition of those committed to addressing the digital divide by making them visible to each other.
The purpose of this post was not in any way intended to condemn the culture of open source communities. The collaborative research process of the Digital Divide group embodies the DIWO (Do It With Others) ethos that I so dearly adore about hacker culture – though it’s doubtful that many members of the group self-identify as hackers. Tidepools, the open source neighborhood mapping project I’ve been working on, was developed under the direct input of the Red Hook community through a unique hybridization of technological development rooted in ethnographic process. I’ve become ever more passionate about the intersections between cultures, the power and potential of fusing worlds. That excitement and fervor has found me racing between spaces, places, communities and meetings – constantly in action, constantly iterating an idea into refinement without allowing it to grow. Borrowing from the best of both open source culture and anthropology, I’m committing this blog to being a living testimony to transparent documentation, reflexivity and critical thinking – but for that to happen, I have to learn to slow down and allow thought to crystallize into language. Here’s to slow dev! 😉
As I launch into week 5 of my work with the Open Technology Institute, I’ve begun to collaborate with a variety of groups, organizations and actors who constitute part of the emerging network of activity around developing community mesh networks and mapping applications in Oakland, California. The idea is to facilitate the grassroots (bottom-up) development of community mesh and mapping initiatives already ongoing in the East Bay, while playing a supporting role in documenting progress and connecting communities of interest.
sudo room is a young hackerspace in uptown Oakland dedicated to transparency, social justice and the creative application of technology. Sudo room is an open, inclusive space for free education and access to tools, as well as a venue for hosting local civic hacking, technology and learning initiatives. The groups and projects detailed below meet at and work regularly out of sudo room, which serves as an ongoing hub for events ranging from 72-hour hackathons to meetings between city projects and local hackers.
510pen Network Map, with currently-inactive sudo room node information displayed.
510pen is an East Bay community mesh network started by Mark Burdett in 2009. Currently, most of the nodes that were set up between 2009 and 2011 are inactive and in need of tech support. As of last week, we’ve begun meeting weekly at sudo room to discuss basic hows and whys of community mesh networks; wireless network hardware and software; how various community wireless efforts can cooperate and collaborate; models for organic growth, organization, support and sustainability; and how we can join forces with local residents, small businesses, non-profits, municipalities and anyone else to build a ubiquitous community mesh network.
Oakland Wiki is a LocalWiki repository for documenting the infrastructure, communities, and history of Oakland. Oakland Wiki hosts weekly edit-a-thons at the Oakland History Museum, where older residents / historians meet with the Oakland Wiki team to document the history of Oakland. Oakland Wiki is also hosting a civic data session at Open Data Day on February 23rd. The goal of this session is to provide a qualitative focus to an otherwise quantitatively-focused event, encouraging the contribution of information about city council, city policies, politics, and key figures in the city – essentially creating narratives around the past, present, and future of the city in an accessible and historically-rich manner.
Oakland Wiki: Mural Lane
The Open Oakland Digital Divide Group is a collaborative effort to coordinate the various organizations and individuals working on digital divide issues in Oakland. Spawned out of a session at CityCamp Oakland last December, the group consists of local citizens, technologists, and community change workers interested in creating solutions for effectively addressing the digital divide in Oakland. At our first meeting, held on January 24th, we articulated a few tangible goals to work on: individually reaching out to preexisting groups addressing digital divide issues to assess their needs and available resources; group field trips, visiting for instance a local swap meet where broken computers are donated to a group that turns them into working machines; and creating a central directory of digital divide resources for the city, including for instance a map of local, free tech meetups.
These are just a few of the most prominent players and projects as we move forward in developing relationships with community organizations and neighborhood groups. I will continue to transparently document my ongoing research progress at the Tidepools Wiki, and welcome your comments and contributions in the comments of this post!
