Hackerspace Design Patterns 2.0

From Noisebridge
Jump to navigation Jump to search

Wanted: your Hackerspace Design Patterns[edit]

I submitted a proposal for a talk at CCCamp 2015: an updated presentation of the Hackerspace Design Patterns. It was accepted!

Hackerspace Design Patterns 2.0 Talk at CCCamp2015
When: Day 3, Occurred on Saturday 15-August from 10:30am to 11:00am.
Where: Project 2501 Tent (aka: Tent A)

Immediately following the Talk, I led a Workshop / Discussion. All were welcome! If you were just curious, or if you were interested talking about what has worked well (and what has not worked so well) at your space, then let's keep on discussing and distilling out new Patterns to add to the Hackerspace Design Patterns for all hackerspaces (forming, new, and old) to benefit from, far into the future.
Hackerspace Design Patterns 2.0 Workshop at CCCamp2015
When: Occurred on Day 3, Saturday 15-August from 11:15am to 1:30pm.
Where: Norton's Obscure Phoggy Embassy (NOPE) Village (aka: the Noisebridge / Sudo Room Village)


Have you observed a Pattern (what works well, and what not so well) at your hackerspace that you think others can benefit from? If so, please share it with me, so I can continue to share it with others in my future talks.

mitch AT CornfieldElectronics DOT com

Design Patterns[edit]

Design Patterns are generalize-able statements of what works well and doesn't work so well -- so that others can learn what may work well (or not so well) for them.

Hackerspace Design Patterns[edit]

The original Hackerspace Design Patterns was presented at CCCamp 2007 and 24C3 when there were only ~40 hackerspaces in the world. Here's the original Design Patterns (which are way worth reading!):
These patterns directly inspired the creation of the hackerspace movement. Now that there are over 2,000 hackerspaces listed on hackerspaces.org, it's time to update the Hackerspace Design Patterns to include 8 years of additional collective experience -- and present them at CCCamp 2015.

Somewhat updated Hackerspace Design Patterns[edit]

A somewhat updated version (that needs more updating) of the Hackerspace Design Patterns are listed at hackerspaces.org:

Your Observations Wanted[edit]

Do you have any observations of what works well, and what doesn't work so well at your hackerspace (or any hackerspace)? Can you state it in a way that may be generalized so that people starting (or running) hackerspaces may benefit from your observation? If so, please send me your observation, and I'll incorporate it into my future talks.

mitch AT CornfieldElectronics DOT com

Workshop after the talk at CCCamp 2015[edit]

My 30-minute talk at CCCamp 2015 included some old and some new examples. After the talk, we had a workshop on Hackerspace Design Patterns, and really got into what works well and doesn't work well at hackerspaces. I took notes, wrote it up, and posted it so that everyone starting or running a hackerspace can benefit from our collective experiences.


New Hackerspace Design Patterns[edit]

The following were provided to me by several people from several hackerspaces:

Please feel free to add your new Patterns here:

Physics Pattern (source)
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.

API Pattern (source)
Problem: Hackers don't like unnecessary rules, and rules are often unenforceable. Check out link about repercussions of Rule-making overload.
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.

The Focus-Group Pattern.
Problem: A change to the rules has led to outcry from a set of members. The problem fundamentally hinges around a particular topic (e.g. inclusivity, feminism, etc).
Solution: A meeting is held at regular intervals to discuss the issue by any member who a) effected the change, b) is affected by the change or c) feels the change is inappropriate.
NB: Have these off-site, somewhere nice, like a local restaurant. Around food.

The Cabin Fever Pattern.
Problem: A contentious disagreement breaks out between a large number of members. The topic varies, but the contention occurs on a semi-regular basis. For example, at the end of January/beginning of February (northern hemisphere). Or every 4 months.
Solution: The topic may be valid, but it's important to examine the root of the -vigorousness- of the disagreement. Are external/seasonal influences affecting the members? Sometimes people start fights to blow off steam. If the time of year or weather is affecting the members, make sure that important decisions aren't being adversely influenced by seasonal concerns. If regular steam-blowing is needed, establish a regular series of group projects/common goals to give people something to focus their energy on, instead of directing it at each other, and set the cycle length to complement the existing cycle of contention.

The Anti-Sponsoring Anti-Pattern.
Problem: Independence is cool, but rent needs to be paid.
Solution: Hackerspaces in big places (like tens of thousands of sqft industrial-zone warehouses) can benefit from occasional bumps in funding availability. This doesn't mean you should feed off someone else forever as a space; however, the occasional "yes we will take your no-strings-attached dollars with a comma and some zeros" is a weighted decision. Supplement and be in the black for longer when possible.

The Space-Sharing Pattern:
Problem: Your hackerspace could use with some income $upplementing. A group that some of your members are a part of needs a space to work or hold meetings in.
Solution: Pimp the space and offer at a (reasonable) price the usage of the space in off-times by groups. Be willing to be flexible for each group and work out a *signed* agreement -- contract or Notary Public letter to one another. A usage schedule may need to be established for popular tools.

Converse Anti-Pattern: Now there's stuff sitting in the middle of your shop that isn't really the responsibility of any of your members.
Solution: Have a solid mechanism in place for dealing with junk. PS:One's Tidyspace policy is good at removing junk in a fair way.

The Viewers Like You Pattern.
Problem: Your hackerspace needs money.
Solution: Run a fundrai$ing campaign, NPR style. Tote-bags and coupon books 'n all.

Converse Anti-Pattern: You run the campaign$ and can't make up on your printed totes, or you're running them every month.

The Who's on First Anti-Pattern.
Problem: Your core workings of the space are dependent on several people being there. The question "Who do I give money to" is greeted with "Uhhhhhhhhhhhhhhhhhhhhhh". The question "How do I become a member?" is answered with "You'd talk to... J. Hacker, who's... not here tonight."
Solution: If a single person is necessary for a single task, there should be several. If that task is common, or involves the running of the space, that person should *be there* when the door is open or available* more often than not.

The person who takes money should be there every night. At open time. If you're a 24/7 space, there should be some *way* to contact said person *easily* -- and it should be **KNOWN**.

Spreadsheet Pledges Funding Pattern:
There is a large piece of equipment that several people want, but that your space cannot afford. Create a spreadsheet and have members enter pledges. When the total pledged amount exceeds the cost of the item, call in the pledges and purchase the item. It is important that pledgers understand that they will not be paid back -- they are paying to bring useful equipment into the space. Only pledge what this is worth to you.

The Resource Replenishment pattern. (Extension of the Club-Mate pattern.)
Problem: A particular resource (soda/beer/H2O2/C3H7OH) is consistently in limited availability and nobody knows who should buy it.
Solution: The person who is most able (supply) and who uses the most (demand) provides replenishment during phases of heavy use. A member of the space who is qualified to handle funds should take allocated funds and replenish supplies.
(common implementation: the Quelab soda fridge is replenished often by people who want a particular soda, which is commonly on sale alongside other sodas. Funds collected from the usage of soda, beer,etc go into buying more soda, beer, hydrogen peroxide, isopropyl alcohol, ...etc. respectively.)

Don’t have a kitchen at your space. Nothing turns a group of diverse individuals into competing cliques like using your hackerspace as shared living quarters. Have a fridge that is cleaned once a week, whether it needs it or not, whether you think food should be thrown away or not (it should).

Nothing kills community spaces like apathy when bad things happen. Be aware of individuals bringing bad things into the space and address them early. When many such individuals crowd a space, they kill the creative energy of others by swamping them with drama. This in turn causes people to ignore bad behaviors, giving implicit permission and inviting more of the same bad behavior. Community is hard, and you should deal with such issues as they arise, and not let them gather.

Creative Chaos Pattern: The Stage Fright Anti Pattern:
Problem: As a group grows and becomes noticed in media and the surrounding local community, its solo, group, and public projects as well as public events are perceived differently. This can lead to higher assumed expectations that outpace the output of quality, speed, and/or intricacy, and can tie in with some other Hackerspace Design Patterns. This can be affected by the Sine Curve Design Pattern, for instance. This can affect any of the following: new guests who may feel intimidated before even arriving or as a diametric who expect to see robots greet them with 3d printed bon bons, new as well as longstanding guests and members who attempt to discourage projects of perceived lower quality, members and recurring guests who begin to feel pressured into producing higher quality or participating with more effort, the general public, leaders in the community who are not a part of the Hackerspace, local and global media, partners, and sponsors.
Solution: Clearly identify when public projects and programs are low barrier when announcing them, and communicate which skills and experience are needed for activities with higher participant expectations. Also, clearly identify the intended goal of a project or event when promoting it. Encourage members and patrons to embrace an adventurous side without fear of failure, and elect a community welcome wagon that does things like offer constructive criticism particularly for new guests and members. Have clear paths written on how to best perform a public project or event, with specific expectations detailed. Provide one or more contacts to help members add public activities like workshops, and try to schedule frequent new member orientation classes or less frequent smaller classes about how to add public activities to the Hackerspace's promotional queue and the expectations of running public events. Burning out a core group of volunteers is never a good idea, and some sustainability can be procured from the encouragement of members to create their own public programming in activities and resources. Make it clear that there are multiple tracks of different quality and intricacy expectations. For private solo and group projects, there should really be no expectations outside of the group's charter or general ethos of respecting th e space, peers, and other projects. Discourage elitist policing and be swift and firm. Remind a frustrated member that they may be incurring this Anti Pattern or helping it along, and ask them to find constructive ways of helping that member with their project instead of berating it, or simply ask them to step away and leave the member and their project alone.

Replacement Pattern (source)
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.

Principles Pattern (source)
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.

Mentor Pattern (source)
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.

Caretaker Pattern (source)
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.

Outreach Pattern (source)
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.

Pot-Lock Pattern (source)
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.

Signage Pattern (source)
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.

Anti-Popularity Pattern (source)
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.

Dossier Pattern (source)
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.

Anti-Kibitzer Pattern (source)
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.

Reboot/Refresh Pattern:
When the space is brand new, everyone putting their energy into the space is creating something new, and are excited about it, and bond over it. After a few years, people come and go, and that feeling and energy of new-ness is gone -- and people who are newer to the space have the sense that the space has existed long before them, and will continue on its own. Also, the culture of the space changes over time. Some bad behaviors might start creeping in. And some people who have been putting lots and lots of their time and energy into the space tend to get burned out.
Solution: When you're OS isn't working so well, turn it off and on again! This often helps! So, have a Reboot for your space! Close the space for a month, and only let in people who are helping fix up the space. It's very bonding. It renews the feeling of new-ness, the feeling that each person has that they are creating the space that they are wanting to be a part of. And don't let in people who don't belong. After opening again, keep attracting people who belong (i.e., people who both benefit and contribute to the space -- and "contribute" can be in many forms: financial, cleaning, fixing, giving classes/workshops, learning cool things, sharing their positivity, making people at the space feel good, whatever people at the space feel is positive); and keep people out who are bad for the space. This collective behavior keeps the "cultural immune system" of the space healthy and strong. Have a mini-Reboot annually to regenerate this year after year.
An alternative to a Reboot: is to have a Big Project that gets a majority (or, ideally, all) of the people at the space psyched to be helping bring to reality.