hacker dojo

Hi, my name is Kitt Hodsden. I'm a founding director of Hacker Dojo.

from dusk to dawn

Back in January of 2005, a group of friends gathered together to have the equivalent of a reverse LAN party: instead of playing games from dusk until dawn, they pondered creating games from dusk until dawn.

Okay, maybe not so elaborate as building a game in twenty four hours, but definitely a party where the focus was to build something in 12 or so hours, and show it off in the morning over breakfast.

(pbworks )

Of the twelve people who started that evening, six made it to morning. From that weekend, one project survived. It's doing pretty well.

(shdh)

The party happened again the next month, then continued every four to six weeks after that. While the event itself grew in size, it varied in timing and location. It grew beyond the house specifically, and into sponsored locations, such as SocialText, Sun Microsystems and Google.

At Super Happy Dev House 30, in January 2009, at Sun Microsystems, we hit a local maximum of 376 people, and the organizers had to ask, what if we could have a dev house 24 hours a day? How awesome would that be?

scratch own itch

Looking around at various venues that existed, options for a 24/7 Super Happy Dev House equivalent were limited to coworking spaces where, sure you build stuff, but the sense of community where you turn to the guy next to you and ask, "Hey, I have this loading issue on my node-js project, have a second?" is sorely lacking. In a coworking space, the focus is on working, and less on the social aspects that are a significant aspect of SuperHappyDevHouse.

Other options for community include existing hacker spaces. The only problem with existing hacker spaces was, there weren't any in the South Bay where a significant number of the organizers of Super Happy Dev House lived.

¡not invented here!

While there may have been some parts of the "Not Invented Here" syndrome going one, in reality, there wasn't a space in the South Bay that had the vibe, the feel, the openness of SuperHappyDevHouse, so, like most open source project, we scratched our itch.

We created what we were looking for.

many eyes make bugs shallow

Because we started with the SuperHappyDevHouse community, and drew from an existing group of people who already had both a passion for building stuff and a tangifiable interest in a hacker space with the same feel as SuperHappyDevHouse, we were able to hit the ground running with the many eyes that make bugs shallow.

Also known as many hands make light work.

(build out )

The weekend after we received the keys to the building, we hosted a build out session. We had about twenty people show up to clean up the space and start to make it ours. The space was previously a stained glass manufacturing facility, and already had character, so we cleaned it up, painted the walls that needed painting, repaired the parts that needed repairing, like large portions of the electrical system, and received donations of tables and chairs and couches and other furniture.

patches count

When a project is starting out, and even when it's bigger, the effort and results of those interested in the success of the project is what counts most. Those most interested in the Dojo are the ones who helped it succeed early in the beginning, and helped it grow to what it is today.

In come cases, our patches were time. People came out to help with the build out, some people helped staff the facility, some people made connections for us.

Every contribution helped. We had a half dozen people sign up to be members who have never been to the Dojo. They believed in the idea enough that even if they weren't taking advantages of the facilities, they still believed in the idea, and contributed financially.

free as in speech, not as in puppies

One of the important reasons for the success of the Dojo is the financial support of the members.

Okay, you might be wondering why I didn't say "free as in beer." The issue is that with beer, you buy it once, you drink it, you're done. Open source isn't like that. You create something, you maintain it for a lifetime. With puppies, you buy it food, you pay for its shots, you pay the vet, there are a lot of expenses and bunch of time involved. It's not just pay once and you're done. Open source creating is more like a puppy than a beer.

Running a company, and the Dojo is a company, it's a not-for-profit company, but it is still a company. The company pays the rent on the facility, pays for the lights and the heat, pays for the fibre network for fast internet even with 400 people connecting three devices each, pays for building improvements.

As such, we need a revenue stream.

From day one, we charged for membership. Members pay the rent, for the lights, for the fast internet. While we do have a hardship rate for students and the unemployed, and a work-trade programs for those who have time but not the money to be a member, every member pays for the facility use.

That we had raised enough money for two months rent before we opened and that we started charging on day one was crucial to our success.

has no owner

So, yeah, members, they pay the rent, they keep the doors open. Just as ideally open source software has no owner, or perhaps many owners, the Dojo has no owner per se.

At the Dojo, any member can attend any event or be in any space at the Dojo and any time. This is true for paid events and classes. The reason the space continues to exist is because the members pay for it, so it is important that the members have access to the facility. For events such as classes, members are not allowed to be disruptive, nor are they allowed access to class materials unless the instructor is willing to provide them.

Another aspect of having no owner is that everything at the dojo is communal. People bring in items to donate, such as desks and books and refrigerators and electrical equipment and monitors. If an item is left at the Dojo, it is assumed to be communal property. Monitors and food are pretty much the only things that can be labelled and claimed. With food, you don't eat it; with monitors, anyone can use an open one, but you're asked to give it up if the owner wishes to use it.

An aspect of everything is communal is that when donating items or leaving things at the Dojo, it is understood that someone else can come along and use it, abuse it, change it, break it, or possibly throw it out. This happens and it's part of the rules.

experimenting

Because we encourage experimenting, we encourage trying new things.

Fundamentally, Hacker Dojo is one big experiment. We realize a problem, we think of possible solutions, we try things. If something works, we do more of it. If something doesn't work, we try to figure out why it didn't work, improve upon the solution and try again.

When we first opened the Dojo, going for the 24/7 aspect of keeping the Dojo open was hard. We initially went with the traditional staffing model: we had a calendar where people could sign up for time slots, we published a calendar, we gave staff keys to the front door, the Dojo was open when staff was around. We had weekly staff meetings.

Yeah, you see where this is going, right?

The problem with this method, oh, yes, anyone who has worked on an open source project or even in a volunteer organizations knows this one, once a task becomes onerous, once it becomes tedious, once someone demands a certain action, meh, it's no longer fun: it's work. There isn't any benefit to the members who are staffing, it's not like they're getting paid: more responsibility but no benefits.

Yeah, not going to work.

We struggled to fully staff the dojo. Oh, sure, members who had keys were there, but they weren't staffing. Keys were copied and handed out without any tracking, sometimes to non-members. The doors didn't open, people forgot to show up or remove their signup the week they went on vacation. It degenerated into a chaotic mess.

So, we changed things up. We experimented.

A maglock was installed on the front door. Anyone who had been a member for 60 days (now 30) could sign up for their RFID tag to gain entrance into the building. If you were willing to be available to help others, you could unlock the Dojo and open it for everyone.

This process worked. We experimented, we iterated, we found something that worked and we went with it.

rapid feedback

We've done this with other items, too.

Besides the big ones of staffing and opening and closing the Dojo, figuring out the rules we all agree to was another big one.

Initially, on this we floundered. We had our basic rule of Anarchy with Respect. Anything goes, have at it, as long as it doesn't interfere with the rights or resources of another member. People want more than that. People want rules to be well-defined so that we know we're all playing by the same rulebook. We, as directors, however, didn't want to make the rules: the community needed to define those rules.

Except how do we define how to define the rules?

Initially the staff created the rules, since the staff were the most passionate members of the Dojo and had the most invested in the Dojo since they were around the most. Quickly, however it became obvious that we had passionate members who were not able to staff, but still wanted to voice.

After a few iterations, we settled on our Polar Bear Wrestling meeting. Any member can propose a rule, a concrete, well defined, easily understood and enforced rule. The proposal time cuts off two days before the meeting. At the meeting, any member in attendance voice. All discussion happens before the meeting, so the meeting doesn't drag on. The rules are enforcable so voting is easy. Progress is made and we are able to iterate quickly.

no central authority

Removing the central authority figure, the staff, from the equation and enabling the members to control how open and closed the dojo, figuring out how to create the rules, other experiments in how Hacker Dojo operations work, they are all all part of a key aspect of the culture at Hacker Dojo, and that is everyone has the opportunity to change the rules and the authority to enforce the rules.

This is awkward for some people. Some people don't understand, "Just do it!" They ask permission first. They look for the authority figure to bless a project before just starting it.

(pink room )

The Dojo doesn't work that way.

If you want to paint a room pink as an April Fools joke, go buy the paint and start painting. If you want to install a giant Koosh ball or your airplane on the ceiling, have at it. If you want to have a Art Hack Day and make the Dojo cool, have at it.

Removing authority, telling people, "don't ask, just do," "just submit the patch already!" is a hard change for some people, but awesome for those who do get it.

oh but wait

Now, to tell you all the great stuff with Hacker Dojo and how it's the bright and shiny example of a physical manifestation of the open source ethos, without following it up and telling you also about the not-so-bright and shiny parts of the Hacker Dojo, would be a disservice to all of you, and quite dishonest.

Because it's not all bright and shiny. Where there are people, there will be strife of some flavor.

trolls

We have had our share of trolls.

In a physical space, this typically means someone is being disruptive or possibly abusive.

Every member has both the right and the responsibility to enforce the community set Hacker Dojo rules. The facility is, however, open to the public. We allow guests of members as well as non-affiliated visitors. We don't have a filtering process that judges people who come in, we assume everyone is good until they prove otherwise.

And, in some cases, they do prove otherwise.

We had one homeless fellow who moved into the Dojo. We don't allow storage of items, recall anything left at the Dojo becomes community property. When he was (rightly) confronted about his stuff being stored at the Dojo by a member, he became hostile. He started yelling, he started cursing, he started accusing all the members within earshot of being "With the Man" and "beating his people down."

It can be hard to be calm when someone is screaming race in your face. The best thing you can do is to ask him to leave, and help him out the door when he obliges. Which is what we did: I asked him to leave, another member moved him and his stuff to a homeless shelter.

We had another case of a member who never showered. He would sit non-stop all day in one of the small offices we have, to the point where the room smelled so bad that even the member couldn't use it after two days, so he'd move to another small office and repeat.

Technically not against the rules, but sleeping in the Dojo parking lot, and parking for more than 48 hours straight in the lots were.

Yeah. At this point, I became the bad guy.

I asked him to leave.

This is the equivalent to banning in most open source projects. A community polices its own, and in this case someone who didn't fit in, his ideas or methodologies didn't fit in with the direction the project was going. It happens.

But the cases aren't always so cut and dry, so obvious, that, okay, let's kick this member, this contributor, out..

Early in the beginning of Hacker Dojo, a lot of communication was across the mailing lists. We had one person jump on the list and ask if we could accomodate his specific project in the space. His project was outside of our expected and supported hardware and software development spaces.

Now, we had specifically said, everything was communal, no one could claim a space for himself, set up shop and bar everyone from using the space. Given that everything is communal, we couldn't guarantee his project wouldn't be touched, altered or destroyed. Worse, he couldn't guarantee the safety of the remaining membership should his experiments, um, explode or spill.

When some members said no, we weren't going to accomodate his project. When this happened, the person became a little aggressive, possibly a little hostile, depending on how sensitive you are.

Eventually, we called him on it. We gave the answer we have learned to give for people who have crazy, though potentially awesome, ideas that in the future could work wonderfully in our space: lead the project: tell us what it is going to take for your project to succeed, develop a game plan, put in the safety measures, find supporters, work up a budget, start the fundraising, make it happen.

The community defines itself. If the community decides it wants to become a metalsmithing shop or an experimental biology lab, it'll become that, because that's what the community wants.

all talk, no action

Another aspect of open source development we encountered, an aspect that is also found in just about every volunteer organization ever, are the troll subspecies "we oughta."

The we-oughtas clan is often very vocal, they know what we should be doing. When it comes to the actual _doing_ however, they aren't around, they aren't available, or that's not what they meant.

When this is the case, the response is either, that's nice, and ignore it, or, just as in open source projects, "put up or shut up." Essentially, if you're not willing to put forth the effort of leading your own project - even if that leading is just finding someone else to lead your project - we're not going to follow.

politics

Any group over the size of one starts to have politics, the manuevering of positions to create opinion on your side of the issue.

For the most part, we believe in the anarchy with respect motto, and that everyone at the Dojo is an adult. I'm going to define being an adult as talking with the person you're having difficulties with, you don't just ignore the problem or gossip or avoid the issue until it grows into a huge problem.

Because members don't need to ask permission before modifying aspects of the Dojo, problems do arise. We encourage people who have concerns or issues or problems to talk to other party, face to face if possible, and resolve the issue between themselves. It's surprising how many conflicts can be resolved by face to face talk.

Sometimes they aren't resolved easily, and we do have others step in. It's just part of the process.

transparency

One of the biggest elements in minimizing conflict so that everyone is moving in a positive direction is transparency. Exposing data is a first step. This is not a default position for some people, and is sometimes difficult.

We address this by exposing as much of the internal workings of the Dojo as possible. We have monthly membership meetings where people meet the other members of the dojo. We have a director present the State of the Dojo, which helps us all understand the size of the Dojo in terms of membership, as well as the financial health of the Dojo.

(numbers )

All of the rules are published on the Dojo website, with the rules being updated and changed by those most interested in helping the Dojo become a better place. We used to have a log where people staffing the Dojo could report issues of the day. We don't use the log so much any more, and I feel its loss is a detriment to the parts of the community who don't know the day to day aspects of the space.

We're iterating though. We're trying to to build that back in.

Communication is a tough nut to crack

fork it

Even with all the good stuff minimizing nearly all of the bad stuff, sometimes things just don't work out on a project. Given one of the basic tenants of the open source is the ability to copy and modify the source, and given the slide I just put up, you know that I'm going to say, if it's not working, fork it.

A huge reason for Hacker Dojo's success is based on the existence and support of the SuperHappyDevHouse community. Because of that community, we were able to gauge interest level, find people who shared a desire for a hacker space in the South Bay, and generate financial commitments to the idea.

That community made Hacker Dojo successful.

It's a model that can be duplicated.

hackerdojo code

Practically speaking, the code that runs much of Hacker Dojo is available on github. This includes our membership tracking, as well as our subscription payment processor integration. It includes our events system, a number of our reporting tools, LED sign controls, and a number of other applications.

It's available for use, and we welcome any patches.

phew!

As a physical manifestation of the open source ethos, Hacker Dojo is a pretty awesome place. I encourage anyone living or visiting the area to stop by Hacker Dojo, tour it, work from it, and play at it. Depending on your circumstances, either stay and make it more awesome, or create your own.

- members get access to all events, even paid
- only members can put on events (or sponsor others)
- everything is communal that shows up except food and monitors if you label them
- experimenting
    - staffing? too much commitment. didn't work. disaster.
    - need dojo open when members are here — installed maglock that you get access to after 30 days (kind of like commit access)
    - experimenting gives rapid feedback
    - defining rules
        - people freak out when you say "no rules!"
        - operating under conflicting rulesets
        - didn't want to dictate rules from on high
        - wanted to avoid disenfranchisement caused by not being able to make meeting
        - Led to: polar bear wrestling - rule making sessions
            - proposal for rules due 2 days before
            - must be concrete and enforcable
            - removes central authority
                - don't want a management group if the dojo can manage itself
                - any member has the right and responsibility to enforce the rules
                - really, really hard for some people who need to ask authority
- It's not all good, there are still trolls
    - in real life, there's risk of physical altercation
    - facility is open to guests of members, but also to unaffiliated visitors
    - assume everyone is good until proved otherwise
    - had a homeless guy show up, move his stuff in, and get upset when told that it was no communal — banned
    - things that don't quite fit the space: submit the patch. 
       (define the project, get people on board, write up budget, develop safety plan, then come back )
    - all talk, no action — tell them to do the work
- politics
    - assume that everyone at the dojo is an adult
    - as open as possible
      - rules are published on the wiki
      - onboarding process
      - monthly membership meetings
      - polar bear wrestling
      - state of the dojo
      - expose finances
      - expose member metrics
- fork it
    - you can start your own
    - code written for the space is online at http://github.com/hackerdojo
- all of this info, including a prerecorded version of the talk at http://ki.tt/osb11

- questions
    - what decision-making process at polar bear wrestling?
      - majority wins. the people who are there are the people who are passionate.
    - how does the board work?
      - write up agenda of short-term and long-term items
      - short-term
        - board can veto any rule that's not in the spirit of the dojo
        - budgeting

    - how many people?
        - 276 members
        - 40 before noon
        - 80ish all day
        - 15 – 200 more for events
        - space holds 350
        - looking at expanding to accommodate cubicles and quiet workspace
        
    - what sort of work is done?
        - a lot of coworking during the day
        - small companies start there

    - access control
        - we don't check IDs, open to the public
        - non-members get slow DSL

    - what kind of space is it, and where?
        - industrial space
        - warehouse
        - giant roll-up door
        - offices with natural light
        - larger areas without 
    
    - space reservations?
        - space is reserved for events
        - 1 of 3 offices is reservable by a piece of paper
    
    - how much go guests pay?
        - $10/day suggested donation
        - (and then you get fast internet)
        - people need to sign in, but don't do other checking
        - really careful not to make rules against the one bad apple, wait for the second

    - how long has it existed?
        Aug 2009 opening
    
    - what's the hardware section like?
        - hardware room is an electronics lab
        - have had people ask to build larger robotics, but this hadn't worked because of no private property/reserved space
        - trying to figure out larger projects

    - why do you call it anarchy and how would other members feel about that term?
        - "anarchy with respect" tagline came from david weekly, 
           one of the original superhappydevhouse founders. 
           was his fundamental philosophy for opening a hackerspace
    
    - how have you prevented someone from being seen as an authority figure?
        - the community polices its own fairly well
        - people ignore getting bossed around
        - when there are issues, the board has stepped in
        - board members occasionally have been called to come in and solve something 
           (but most times it's been solved by the time they got there)
    
    - costs?
        - $100
        - $40 hardship month
        - work trade option (typically for established members)
    
    - transit? 
        - had to be w/in a mile of caltrain (15 minute walk)