These notes were taken live at the University of Michigan School of Information on October 23, 2015.
Jane Berliss-Vincent: Assistive Technology Manager at the University of Michigan, author of Making the Library Accessible for All.
Terry Soave: Manager of Outreach & Neighborhood Services at the Washtenaw Library for the Blind and Physically Disabled and Ann Arbor District Library.
Carolyn Grawi: Executive Director of the Center for Independent Living.
Paul Barrow: Public Services Librarian at MLibrary.
Joyce Simowski: Information Services/Outreach Librarian at Canton Public Library.
Melanie Yergeau (Moderator): Assistant Professor at University of Michigan Department of English Language and Literature, with a focus on Disability Studies.
Melanie begins by introducing the panelists. Paul works on facilities and front desk issues. His first job was working for a man with Cerebral Palsy and the lessons he learned have stayed with him. Joyce works with older adults. Jane, a UMSI alum, wears many hats, including makeing sure the University of Michigan public computers have accessible technology, and collaborating on web accessibility. Terry builds partnerships with community organizations in order to reach populations that aren't typically engaging with library services. Carolyn works with individuals having many types of disabilities at the Center for Independent Living, and has more than one disability herself.
Paul has increasingly observed that individuals with disabilities are not identifying publicly and asks how to help them. Carolyn suggests making it clear on materials that it's ok to ask for accommodations. Some accommodations can be expensive, but if you know ahead of time which ones are needed, you can avoid unnecessary expenses. Terry stresses that you have to know your community because it's impossible to accommodate everyone all of the time. You can put up a sign, but if someone can't read it, what do you do next? Terry adds that it's very challenging to understand the things that you take for granted when working with someone who has a disability. Terry tries to make it easier to do that.
Jane tells a story about going to AADL with Jack Bernard, Associate General Counsel at UMich. They went around to different desks and asked whether the library had accommodations for disabilities. Everyone was respectful and knew how to access resources. Carolyn adds that when those resources are easily available to the disabled community, they are beneficial to everyone.
Jane describes how universities are accommodating a wider range of disabilities: learning disabilities, etc., when a couple decades ago, the university worked mostly with sight disabilities.
Audience question: Is anyone providing healthcare accessibility?
Jane: receiving healthcare often involves filling out inaccessible forms with small print, which may not be available in languages other than English. Carolyn just met with a group of medical students learning about compassionate care. There's definitely involvement, but she wishes there was more. A lot of what already exists would benefit from being more standardized. Medical students have to meet with community services, but not every student can meet with every service. It's key for those students to share their that information with each other. She adds that it's important to include the person with the disability: "Nothing about us without us."
Melanie asks whether anyone is collaborating with disability organizations. She gives the example of autism. In autism awareness month, groups like libraries can create well-meaning but ill-advised displays and programs, like advertising organizations that promote misinformation, offering programs that exclude the autistic individuals. Jane talks about the importance of a back and forth dialog. You can't know what people want unless you et them involved and ask them. Carolyn: the Ann Arbor CIL works closely with many organizations. One example was working with the AADL to make the front entrance more accessible. Collaboration isn't always simple, but it's beneficial. Carolyn gives another example, of working with fourth graders in public schools. Why fourth graders? They are at an age where they are open to learning, like to share what they learn with each other, and speak up about the things that they need themselves. A student who had taken one of the workshops once ran into the workshop leader at a theme park and told them what they thought the park was doing right and wrong.
Audience question: How to you ensure that the population you're serving is aware of your services? Terry has outreach staff, works with doctors offices to put information in waiting rooms, and also provides institutional accounts to other institutions that may be working with elligible individuals. By far most people learn about services by word of mouth. Places a sticker for a large-print service inside all of the library's large print books. People like to help, and making connections is an easy way to help. Carolyn: now you can access a lot of materials digitally, so you don't need to come in physically. That can be good for individuals with disabilities but can make it difficult to provide them with information.
Joyce tries to determine and respond to the needs of the community. Carolyn: we all try to follow the ADA and provide "reasonable accomodations." Jane brings up small, light-up magnifiers. They're useful and inexpensive and can be used to provide information to people who need them.
Audience question: how do you deal with the challenge of helping disabled individuals be courteous to those with other disabilities. Jane: sometimes you have "dueling disabilities" like someone who turns a monitor off because the light is a problem, but someone else might not be able to figure out how to turn it back on. It's a challenge. Paul thinks libraries are special because they are a center for conversation. Paul gives the example of moving power outlets from the wall to the table to prevent creating tripping hazards with power cords. Just having a conversation is very powerful. Humans are reactive by nature, so let's react by having a productive conversation. Carolyn agrees that libraries are one of the best places for different types of people to get together.
Audience question: Has background in rural libraries. If you have limited resources, what are the core principles you encourage a library or other public organization to pursue. Jane: listen to your patrons. Finding out what people need may be easier in a small group. Carolyn: maximize your open space. It's useful to more people. Joyce: partnerships can help, like having meals on wheels deliver books. It can be hard to do these collaborations unless they're mutually beneficial, so the collaborations have to be found on a case-by-case basis. Terry: different organizations have different types of funding, which affects which types of collaborations are easier. Paul: libraries used to brag about collections, but they're all the same now. Instead, focus on services. Jane: libraries are not just book collections anymore. In rural areas, they may be points of access for the Internet or job searching.
Audience question: The term "universal design" gets thrown around a lot. What are small changes that make things better for everyone? What is a radical accessible space, and where have you seen one? Jane: Interested by the convergence between "bring your own device" and accessibility. Now universities are moving towards "bring your own everything." Many of the features being used on mobile devices are taken from assistive technology: autocomplete, zoom. The first typewriter-like device was developed by Pellegrino Turri to write letters to his blind friend, Countess Carolina Fantoni da Fivizzano. Carolyn: we try to describe attachments. Having inclusive seating helps: making different types of seating (front, back, etc.) accessible. It's important to be open to feedback and take it as constructive even if it seems critical. Paul wishes that physical spaces were more configurable.
Audience question: The state is putting accessibility as a low priority. What can we do to make it a higher priority? The CIL has ongoing discussions with the state legislature, but sometimes difficult to make progress because of a lack of bipartisan interest.
Closing comments. Jane: think holistically. A towel dispenser may be ADA-compliant, but it doesn't help if you place it where someone in a wheelchair can't reach it. Joyce sees advancements in technology as making a big difference. Be observant of what people need. Carolyn: be patient and tolerant if someone asks for something you don't know or isn't understanding something. Paul: be radical, do what's right, not what people did before.
The wave of hackerspaces in the US over the last decade was triggered, in part, by the collection of the hackerspace design patterns, best practices that had been developed in European hackerspaces. This year at Chaos Communications Camp, Mitch Altman will be presenting an updated list of hackerspace design patterns and has asked the community for input. Here are my contributions based on several years of hackerspace administration.
Problem: Volunteer roles require developing new skills and learning from the successes and failures of past volunteers.
Solution: Volunteers should start training their replacements as soon as they take on a role. Having more members with the necessary skills will make it easier to find a replacement when the time comes. Also, the more members who understand a particular volunteer role, the easier it will be for the volunteer in that role to communicate with the membership.
Problem: Members in a large group have different values, making it difficult to make decisions.
Solution: Early on, create a list of "common principles" or "points of unity" that describe the ideals that were important to the early members. These ideals should be explained to all new members. Debates should be framed in these common principles. Principles can be revised, added, or deleted, but only if there is consensus.
Problem: On-boarding new members is difficult. New members can have trouble finding the resources they need and learning their responsibilities as members.
Solution: Every new member is assigned an experienced member as a mentor. When the member has a question, they can go to the mentor to find the answer. If the member is acting out of line with the group's principles, the mentor can talk to them.
Problem: There are a lot of space usage decisions to make, but most are irrelevant to any particular person.
Solution: Appoint a caretaker for each zone in the space (machine shop, craft room, etc.) The caretaker's contact info is posted publicly in that zone. If a member has a question or a problem in that zone, they can contact the caretaker to fix it. The caretaker gets final say on space usage decisions.
Problem: Your space is almost entirely young, middle-class, white men and anyone else feels less comfortable using the space.
Solution: Actively increase your group's visibility in communities with higher percentages of women and underrepresented minorities. Place more flyers, advertise on mailing lists, and give these groups advance notice of classes and workshops before announcing them to current members and their friends.
Problem: Maintenance and cleaning is boring and no one wants to do it.
Solution: Hold a combination pot luck and lock-in. Everyone works on maintenance and cleaning and takes a break to share home-cooked meals with each other. No one leaves until time is up.
Problem: Members aren't doing something they should.
Solution: Put a signs explaining correct procedure as close to the problem as possible, e.g. stencil "Clear off before you leave" on flat surfaces.
Problem: The group makes a lot of rules, but they are often ignored.
Solution: Instead of creating rules, make it physically impossible to do the wrong thing, e.g. instead of saying "turn the lights out when you're done," put the lights on an automatic timer.
Problem: Hackers don't like unnecessary rules, and rules are often unenforceable.
Solution: Instead of rules, create procedures for solving problems. For example, create a "parking ticket" that members can place on abandoned projects in their way, and a standard way to notify the group about the ticket. Allow anyone to dispose of an abandoned project a certain amount of time after a parking ticket has been issued.
Problem: Conduct complaints turn into popularity contests.
Solution: When discussing conduct complaints, judge actions instead of character. Be clear about which specific actions were inappropriate and why. This has the benefit of reinforcing behavioral norms for other members.
Problem: The board has received a complaint about a member, but the member says they didn't understand the rules. The board members are new and have no way to know whether the member has been a problem before.
Solution: Keep records of all member complaints in a system that is confidential and searchable. Even if someone doesn't want to make a formal complaint, leaving a note can help establish whether there is a pattern of misbehavior and help future boards follow up.
Problem: Everyone has an opinion on how a task should be done, but no one shows up to do it.
Solution: Make it so that members have to put some effort in before they get to have input. Have discussions in committee meetings outside of general meetings, and require homework (e.g. email in proposals beforehand). If someone doesn't show up regularly, or doesn't do constructive work, stop inviting them to the meetings.
The Kickstarter I’ve been running for Seltzer (a tool for managing cooperatives) finished last night, at just shy of 1/3 of the funding goal. While the project wasn’t successfully funded, the crowdfunding campaign was far from a failure.
Over the past few weeks, I’ve learned an incredible amount about who is actually interested in Seltzer, and how much they’re able to participate. I received dozens of encouraging messages from organizers and administrators telling me how much they needed software like Seltzer. And I'm incredibly grateful to everyone who did pledge money to the project. I know many people stretched themselves to give generously. But, in the end, it wasn't enough to fund the project. Several people have told me I should have done an Indiegogo so I’d still get the money that was pledged, but here’s the secret: the campaign was as much about gauging interest as it was about raising money. The main goal of Seltzer has never been to create an application with a specific set of features, but to cultivate an open source community that could work together on an application that meets their common needs. No amount of money can buy that. Now I know that the time isn’t right, and I can apply myself more effectively elsewhere.
So what specifically did I learn? I had expected most of the support to come from people and organizations that were already using Seltzer or at least knew what it was, but I found just the opposite, which might mean that the existing version is actually good enough for everyone using it. I’d also expected many more small-dollar donations but was surprised to see that I got more $40 donations than $10 or $20. Data management isn’t sexy, so I realize now that those small dollar donations needed a more exciting reward to overcome the "sign into Kickstarter" activation energy.
I’d also expected more support from existing hackerspaces, both in the form of larger pledges and encouraging members to make smaller pledges. Members of a few spaces did take this on, but not as many as I’d planned on. The biggest challenge was establishing and maintaining contact. If I could do it again, I’d have started reaching out to hackerspaces months earlier and held regular calls to keep the momentum going. Volunteer organizations move slowly, and are easily distracted.
I’m a little sad that the campaign didn’t get funded, but it’s important to know when to end a project gracefully. So what does this mean for the future of Seltzer? Well, I won’t be developing a new version any time soon. Instead I’ll continue answering questions and reviewing bug-fixes, but no new features, on the existing version. Edit: And don't forget, you can still write your own modules to integrate with the existing code! I’ll also continue organizing people around cooperative software and linked data. If you want to be involved, join the cooperative software mailing list. I’ll also keep following exciting tech developments like JSON-LD. Who knows, maybe there will be a resurgence in interest for Seltzer later on, and I'd certainly consider another crowdfunding campaign, maybe over summer in some future year. In the meantime, it looks like I'll have four-day weekends for the rest of the this summer, so I should be able to relax a bit and catch up on reading and other side-projects.
Last Friday, the CEO of i3 Detroit announced his resignation, and Bucketworks in Milwaukee announced that they were raising money to help make rent (they did). Both announcements generated a lot of valuable discussion about the sustainability of hackerspaces, but there are a few important points that I believe are often overlooked when talking about sustainability.
Growth hurts sustainability. Expanding membership numbers or square footage sounds like a good thing for a hackerspace, but it also carries downsides, especially when that growth happens quickly. More members and more space means more to manage, which means a higher burden on the leaders of a space. A quick influx of new members can weaken the community because those new members take time to learn the group’s social norms (e.g. how to “be excellent,” as so many spaces encourage). It also takes time for new members to learn how to contribute back to the space, so even if they want to, they won’t at first.
At i3 Detroit, they’ve implemented a mentor system where all new members are assigned a mentor (similar to the time-tested big brother/sister system used in fraternities and sororities). Mentors are a single point of contact to help new members get acquainted with the space, its rules, and its values. It’s a new program, but it seems like a great way to tackle the instability that comes with growth, and I have high hopes for it. Have any other spaces tried this technique, or others, to combat the instability associated with rapid growth?
Fundraising is good, saving is better. Many spaces run very close to the break-even point, so when the natural oscillation of membership goes down, or they have to make an unexpected repair, they need to have a “rent party” to quickly come up with money to make ends meet. The alternative is to regularly contribute to an emergency fund. One benefit of such a fund is that even if you still need to have a fundraiser, it buys you time. That extra time opens up new possibilities, like getting more quotes on a repair, or even finding a new space. Plus, extra time makes it a lot easier to continue keeping the space running smoothly for members while dealing with financial issues, without burning out.
But spaces can save for more than just emergencies! Even nonprofit spaces can have investment savings and use interest and dividends to offset operating costs. It takes a long time to build these kinds of savings up, but once you have them, it’s that much easier to weather hard financial times, fund special programs, offer reduced dues for those in need, and so on. Many universities, for instance, use these kinds of funds, called endowments. Similarly, hackerspaces should be considering saving to buy their own buildings. I’m not aware of any that have done this, but owning rather than renting would lower monthly expenses for most spaces (even if they have to get a mortgage) and would prevent the common problem of landlords raising rent after a group has invested in repairs and improvements to their space.
Finally, hackerspaces are businesses. This is a controversial statement, but I believe that if the leaders of a hackerspace aren’t treating it like a business (keeping accurate books, financial planning, catching problems before they snowball, etc.) then they are doing a disservice to the members and setting themselves up to burn out. That said a hackerspace should not feel like a business to the members. Hackerspaces work best when members can come in and just hack, teach, and learn with a minimum of obstacles. In good hackerspaces, the administrators consistently remove those obstacles, and in great hackerspaces they do it before the members even notice them.
There is a lot of good common wisdom floating around on design patterns for hackerspaces and common traps to avoid. Now that so many hackerspaces are up and running, I’m hoping to see more attention turn to how to ways to keep them running, not just for 5 or 10 years, but for future generations.
TL;DR: Inclusion and diversity need to become core hackerspace values. When our spaces lack diversity, we should accept responsibility and take action, not make excuses. A little effort can go a long way.
Everyone running a hackerspace should be thinking about inclusion. There are a few interrelated issues that I keep seeing come up in the hacker/maker/DIY community, and I feel obligated to help give them some of the attention they deserve. Some spaces are doing a really great job at fostering inclusion and diversity, but these values are not yet widely accepted as part of hackerspace culture, and they need to be.
We should care about diversity. All too often, when I talk to members of the hackerspace community about diversity, I'm asked why it matters, or even told outright that encouraging diversity isn't worth the effort. In defense of my fellow hackers, they are also usually quite open to reconsidering their position when presented with good reasons. The reasons fall into two categories: practical, and idealogical.
The practical importance of diversity is simple. Hackerspaces are made of people, and the more awesome people you include, the more awesome your space will be. Diversity doesn't mean, as some might think, lowering the bar for members. It means not pushing away potentially valuable members for silly reasons. It means including everyone who has something to contribute, especially if it's different from what current members are contributing. It means opening up spaces to new socioeconomic groups who will tell you how to make your space relevant to a wider audience, and as a result more stable and sustainable.
But for me, the idealogical importance of diversity is even stronger. The hackerspace movement is about removing artificial technological barriers and using self-education and peer-education to reclaim the ability to make our world. If we leave people out for no reason other than their gender, skin-color, income, etc. then we are the ones placing artificial barriers and hoarding knowledge for our personal and selfish gain. Then we are hypocrites, and doomed to sabotage our ideals.
We have to accept responsibility and promote diversity and inclusion. Another common belief in the hackerspace community is that if we aren't actively discriminating against or excluding people, then there's no problem. But building an inclusive community takes more than that. Demographics are naturally self-reinforcing. Word-of-mouth travels through our social networks, made of people who are likely to share our demographics. When we teach workshops or hold events that are relevant to us, they are most likely to be relevant to an audience who shares our demographic. And there's nothing wrong with that, as long as we acknowledge and correct for it. When you're new to a group it's easy to feel like an outsider, especially if you perceive yourself as somehow different from the group's majority demographic. On top of that, members sometimes unknowingly say or do things that push people away because, through no fault of their own, they've never had to consider different perspectives.
A common response to the gender imbalance in hackerspaces is "Women aren't interested in what we do here." But on closer inspection this is just the "No True Scotsman" fallacy. In effect, it says "We [men] are True Hackers. If you are interested in something we are not interested in, you are not a true hacker and don't belong." To illustrate this point, ask yourself whether a clothes modding workshop or a Starcraft LAN party is more in line with the mission of a typical hackerspace. Then ask yourself which is likely to be better received.
The bottom line of resistance to making a hackerspace more inclusive is often "We don't want to change anything, we like things the way they are." That's a perfectly natural human response, but if it dominates your thinking, you don't have a hackerspace, you have a country club with Arduinos.
What we can do. Luckily, being inclusive is actually not that hard! At i3 Detroit, where I was a co-founder and board member for several years, inclusion was always one of my priorities, and I got a good sense of what works and what doesn't.
Just being actively welcoming to newcomers goes a long way. It doesn't need to be anything complicated, just saying hi, introducing yourself, and asking if they have any questions or if they'd like a tour. Sometimes that's a distraction to members who are in the middle of a project, but specifying best times for newcomers to visit, and a standard onboarding process can make it a lot easier. This is one reason I've never liked the idea of new members requiring a sponsor. Instead I like the idea of accepting anyone who shows interest and offering them a mentor to help integrate them into the group.
It's also crucial to create a safe and welcoming environment. That means having a sensible code of conduct and/or harassment policy. The policy should make it clear that if you're uncomfortable it's ok to voice your concern, and that someone trustworthy will listen, without judgment, and work to restore a safe environment.
Another key is being open-minded about what activities fit into your hackerspace's mission. If you give people the benefit of the doubt, you allow your space to grow beyond what you can currently imagine, and encourage people to push limits and take ownership in the space.
Finally, having a way to include students and other low-income members is important. A guest policy is one way to do that. Tiered memberships are another. A lot of spaces have "starving hacker" rates. At i3, we have two membership levels that are effectively the same, but a good number of people choose to step up to the higher level when they're able. Offering "scholarships" or no-fee memberships for those in financial need can also help. Even if they don't have a lot of money to spend on materials, those members may have awesome skills to share, and may be valuable contributors to group projects. And of course, members often grow through their involvement in hackerspaces. At i3, we had a "founding guest" who helped build the space even though he couldn't afford membership. Four years later, he's now a director and dues-paying member.
The hardest part of inclusivity is realizing that we can't see what's missing, that we have to actively seek it out. The rest is not that hard at all. Once we do that, our spaces benefit from a broader and more diverse membership, and more ties to the community. Some spaces are great at inclusivity, but as a community we still have a ways to go.
If you're part of a hackerspace, is this something your space talks about? What types of things do you do to foster inclusion and diversity? What works? What doesn't?
Over the past couple years, I've been developing a Customer Relationship Management app (CRM) for hackerspaces, and it's now ready to release into the wild! Meet Seltzer CRM!
Seltzer CRM is an open source (GPL) CRM web app for hackerspaces. It's based on the LAMP stack, and has been in use at i3 Detroit for a couple years, growing with us to our current level of 75 members.
There are plenty of CRMs out there already, and even some open source ones, but all of the ones I've come across are rather complicated and have a learning curve before people can use them productively. Seltzer CRM is built around two goals: 1. Be significantly useful to the average hackerspace administrator without any training; 2. Be easy for a typical hackerspace web dev to hack on and extend.
The current features are:
You can try a demo here:
http://elplatt.com/seltzertest (user: admin, pass: beexcellent)
And the code is on github: