You got hackers. They want a fixed space. Now what?
The next question probably comes down to money. The biggest hurdles to bootstrapping and maintaining a Hackerspace involve the management of resources that have actual value. Physical places, even ones which are “free”, require the payment of rent somewhere along the line.
A recent post on the Hackerspaces Discussion list points to the need for the right structure for organizing and managing the finances and resources of a Hackerspace. It’s a question each Hackerspace effort needs to consider carefully and resolve for itself. An organizational structure needs to accomodate each space’s unique culture and reconcile it to the various laws and conditions in play at the time of formation.
The five approaches I outline should be a good starting point for a discussion on the theory of Hackerspace organization. When I look at how Hackerspaces have functioned in the past and how they function today, this framework of five categories seems to make the most sense to me. That being said, odds are good that many spaces will not fit “cleanly” into any of these five categories. Categories are clean, nature is messy. We have to start somewhere.
So, the Five Types of Hackerspace Finance:
- The Angels
- The Owner
- The Board
- The Membership
A few spaces have functioned quite well without an explicitly organized system for managing money. Anarchy, as I use it, doesn’t mean the absence of order or even the absence of money. In this context, I’m describing spaces where needs were met on an ad-hoc basis by those involved. There may not be official dues, but a clear expectation that everyone involved needs to contribute something to make the effort work. Certain Hackerspaces in squats, temporary spaces, basements and other places that can be had for “the taking” are the most common. These efforts tend to prefer completely voluntary contributions and eschew explicit expectations. Some spaces that are officially organized on paper prefer to operate as close to Anarchy as possible, preferring overarching concepts (i.e. “Be Excellent to Each Other”) to specific policies.
It is possible to run a very good hackerspace without any kind of official organization. Were it not for legal matters, liability and a need for explicit order and hierarchies, it might be the preferred choice.
However, lots of reasons make Anarchy very difficult and unwieldy. Often, when dealing with lots of different hackers who have lots of different ways of doing (especially hackers who prefer structure and order) Anarchy just can’t work. There’s also the matter of accommodating new folks who may not share the viewpoints and collectivist spirit that otherwise make this style a possibility.
It’s worth noting that spaces in this category tend to have a strong political nature to them. While this is not an inherently bad thing, spaces that are intensely political tend to alienate or divide people who “just want to hack”.
For me, this is the most difficult category. Angel spaces are ones that rely on outside sources, those that aren’t direct participants, for the vast majority of their support. Hackerspaces in Universities, sponsored by Governments or ones that operate in other businesses without an explicit lease tend fall in this category. Other spaces that may have their own facilities, but could not pay their bills without outside “Angels” fall under this heading.
The natural advantage of an Angel space is that they allow Hackers more time to hack and less time layering on and cutting through red tape. In a perfect world, we’d all be able to rely on Angels to find spaces for us and stock them with all the parts and tools we need to make really cool projects. Of course, we aren’t living in a perfect world.
To be clear, I believe every space should attempt to seek some outside support, either through donated materials, equipment, special project grants, etc. Most spaces do this, but only a handful I know of rely on Angels for ongoing support. As a boostrapping step, calling on Angels is great idea. Recruiting members is often difficult unless you have a space they can see and get excited about, and sometimes you need some help from above to get going.
However, relying on Angels can tend to make groups lazy about their finances, collecting dues or taking other steps to ensure continuity if the Angels pull their funding. Spaces subsidized by Governments or Foundations tend not to plan for crises like what we’ve recently experienced and end up scrambling to survive when the funding comes to an abrupt end. For example, what would have happened to a space funded by a Foundation that fully vested in Bernie Madoff?
The other big problem is that Angel spaces are almost always more constrained in their activities than truly independent ones. Spaces in Universities in the US, for example, are often unable to host parties with Alcohol or make an effort to recruit those who aren’t students or somehow officially affiliated with the host University. There’s also the matter of spaces constraining themselves and their activities so they do not anger or alienate the Angels that support them.
Because my theoretical focus is on continuity and inclusiveness, I’m naturally going to be more critical of Angel spaces. If you’re part of an Angel space and see nothing wrong with it, speak up and say why it’s an ideal situation!
Spaces of old like New Hack City and the Walnut Factory and current spaces like Hackerbot Labs fall under this category. This category might also be called “Single Center of Gravity” because matters of signing the lease, collecting money for the rent and being accountable for liability concerns generally rest on one person’s shoulders. They usually have help and receive funds from those involved, but the money and legal recourse ultimately flows through them. Otherwise, the advantages and disadvantages of spaces run by “The Owner” are largely the same as those for Angel spaces, except the owner is involved and generally the recognized leader of the Hackerspace.
Owners tend to be the de-facto financiers of the space by virtue of being the landlord, responsible for improvements and manager of any activities to raise money. The first Hackerspaces in the US were traditionally founded and managed by one strong personality who probably found it easier to “just do it” than make an effort to start a separate organization and go through the requisite motions to keep it going.
Explicitly for-profit spaces, ones designed to make a profit, are also often started and financed by single entrepreneurs who are ultimately responsible for their operation. These business owners that self-identify their shop as Hackerspaces and make an effort to cultivate community (as opposed to purely customers) are a relatively new thing that warrants close examination.
As far as traditional, non-profit Owner spaces go, the continued success of Hackerbot Labs speaks to the viability of the model. I used to be a much harsher critic of these kinds of spaces, having seen owners get frustrated, give up and call people like me in to help clean up and wind down their space.
However, we need to look at all the models that work. It may just be that your local crew of hackers needs a solid focal point and a single leader in lieu of a more collective form of management.
Most spaces based on the Design Patterns will fall in to either this or the final category. Almost every Hackerspace that takes a corporate form will have a Board of Directors of some kind, as corporate law throughout the world generally requires it. The Design Patterns suggest that Hackerspaces start with a small core of persons who usually comprise the first members and, by default, become the first Board of Directors.
If this small core of persons continues to effectively own and control the Hackerspace, it falls in this category, However, if a space takes the suggestion of the Design Patterns, and hands over effective ownership and control to all those who support the space equally through dues or other means, it falls into the last category,
Sometimes, this isn’t always what you want to do. The question Koen posed in his post is one worth exploring and involves matters of law that differ across borders. Koen’s example cites Dutch law, where a stitching is a board and a vereniging is a membership organization:
“The difficulty is in judging what is right. On the one hand, the democratic principle of a ‘vereniging’ is very much compatible with my idea of how a hackerspace should operate. However, a ‘stichting’ is a safer keeper of things like money and equipment. This might be especially relevant if said money and equipment are injected by external parties. However, the ‘stichting’ can not have members, thus there is no ‘membership fee’: any money asked for usage of the facilities will to the tax office look very much like an entrance fee for a commercial service.”
And herein lies one of the biggest critical distinctions between these last two categories. Do you give members certain administrative control in exchange for their membership dues? Or do you end up paying taxes or losing potential revenue to keep closer control over resources?
Of course, the specific matters of law and taxes and their inherent advantages and disadvantages vary depending on the jurisdiction. In general, the key advantage to a Board is the safety of having more control in the hands of fewer people. The disadvantage is potentially marginalizing those participants who support the space and aren’t on the board. They might lose out on a certain sense of ownership that comes with being a fully member-controlled organization.
Most Hackerspaces based on the Design Patterns fall in this category. Generally, the space is run by members who each a specifically defined contribution in exchange for the benefits of having an equal say in the space’s operation and special privileges like a key, locker, etc. They decide how much to pay in dues, who gets a key, where to locate and so on.
While these spaces will still have a Treasurer to handle the finances, a Secretary to take notes, a President to preside over meetings, etc. what these officers do is ultimately determined by the members. Ideally, every member supports the space equally, through work or dues and gain a sense of equal ownership over the space itself. The members set the agenda, make informed decisions on how to handle administrative matters and give specific direction to the officers.
Of course, there are disadvantages to having a membership organization. What happens when you can’t get a quorum of enough members to make decisions? What if your membership is apathetic to administrative concerns? What if organizing is seen as too burdensome a requirement? Sometimes, as through the first example, the benefits of membership can be effectively conveyed through means other than establishing an official membership organization.
As a quick side note, there are some spaces that are technically organized under one category and functionally operate under another. The classic example is NYCResistor, which is formally organized as a for-profit Limited Liability Corporation (LLC) comprised of the original founders of the space. Legally, they’re an entity run by a subset of the members, putting them in the previous category. Functionally, the larger and ever changing dues-paying membership has an equal say on each issue and they meet every Tuesday to discuss business. The decision to become an LLC ultimately ended up being one of convenience and expedience.
The example of NYCR highlights two things. First, each space may fall into several categories for any number of reasons. (I could make a case that the Metalab falls into all of them!) Second, this is a theoretical construct designed to help illustrate similarities in forms of organization. It’s a starting point for a conversation, not an explicit means of dividing Hackerspaces into groups.
I believe every place where Hackers go to make things and socialize is a valid Hackerspace. Building Hackerspaces that last and are inclusive is a particular emphasis of mine, as I feel every hacker should have a nearby place to go, make, learn and socialize with kindred spirits.
Hackerspaces.org is about bringing all these spaces together and inspiring people to build their own. The aim of this theoretical discussion is giving people the tools and background required to make more Hackerspaces happen. Our emphasis in discussion should be on finding ways to work together, using criticism as a means for identifying pitfalls rather than a blow to the hard work of fellow hackers.
As always, this is just my own milepost in a much larger conversation meant to keep Hackerspaces going throughout the world. Please take it and run with it! The spaces need your thoughts too.