We (Sen and Chris) were really excited about this and have done some initial analysis. Hacklab (like, we think, most hackerspaces) had a lot of sources of data laying around, waiting to be analyzed:

• doorbot (in my opinion, our gold mine)
• Google Calendar
• IRC Traffic
• Twitter Traffic
• Mailing List Traffic
• Blog Hits
• Hacklab Public Computer Activity?

So far, we have only worked with the doorbot data.

Activity Levels

Unless the door has been unlocked, entering Hacklab requires one to use a small fob, unique to each member. The program responsible for processing these, doorbot, will unlock the door if it detects a member. It also logs the entry in a database. This is a valuable source of data about activity at the lab, but there are a number of ways in which it can be flawed. If a member works on a project on the side walk outside, they may enter and leave a number of times in a matter of minutes, but this doesn’t actually mean there was more activity. On the other hand, a member may enter along with another or on when the door is unlocked, making them invisible. Furthermore, Fob’s may be reassigned over time, and we have no way to know who the former owner was. The first concern is mitigated in the following data by considering only the number of entries by unique members each day.

Since the data is really noisy, let’s take a 7 day average to smooth it out a bit:

Looking at this, you may be inclined to suspect seasonal trends, but let’s overlap the years to draw them out.

Again, this is really noisy. Let’s do a 5 day sum to smooth it out.

Interesting observations:

• consistent slump in activity at the end of December (shopping/celebrations keep people away?)
• consistent bump in November
• 2009/2010 have slumps around the Summer but 2011 doesn’t

Another thing to look at is the derivative of Hacklab activity:

Gender Distribution

Another subject of interest is Hacklab’s gender distribution.

To avoid making oppresive assumptions, members were given the opportunity to self-identify their gender. We ended up with the gender categories male, female and other. There were very few responses, so most of this data is based on our understanding of how members identify.

The line for male is blue, the line for female red, and the line for other green. Please ignore any sex-stereotyping in this color scheme.

Again, the data is very rough. Let’s smooth it out with a 5 day sum.

I think that percents may be more useful as a mode of analysis.

Hacklab seems to have been getting better in terms of gender diversity lately, though not as good as we were in mid 2009.

More Graphs!

Some more graphs relating to gender and year comparisons are available. Many more will be coming as we move on with Quantified Hacklab! Also prettier ones, since this was fairly quickly hacked together!

We’re still looking for members to step up to be officers of the corporation – an email will go out to you all shortly.

-Leigh

http://hypatia.ca/2009/03/hacklabto-ignite-at-democampto19/

Slides are up at Slideshare if you just want to see the pretty pictures :)

-Leigh

LDAP is Easy

LDAP is the grandaddy of centralized databases, designed in the early 90s to replace the huge, complex, and expensive X.500 directory protocols. It models the universe as a tree of entries, where each entry has a DN and a set of attributes. DNs are built by selecting an attribute to uniquely identify a given entry at its level of the LDAP tree, so an entry’s DN looks like a list of name=attribute pairs: ou=People,dc=hacklab,dc=to identifies the entry whose ou attribute is “People” and whose parent is the entry dc=hacklab,dc=to.

That’s the entire data model: a tree of dictionaries.

LDAP is Hard

LDAP itself is a only protocol, not a service for any particular use; when people talk about LDAP, what they really mean is “LDAP plus the schemata we’re using.” The schemata define what attributes a given entry can have and how they’re validated, and LDAP client applications, in turn, often expect entries to obey a given schema. Because of LDAP’s X.500 roots, there are many schemata, and it’s not always clear which ones you need for a given task.

The tools around LDAP are the other main source of frustration. While Microsoft Active Directory and the Apple Open Directory tools are extremely high-quality management tools, they’re also relatively expensive and aimed at large deployments. The open-source offerings around LDAP are almost universally very open-ended LDAP frontends. If you’re lucky, they can be customized around however you’re actually using LDAP; if you’re not, they’re barely more useful than the command-line ldap-utils.

In Practice

Hacklab’s LDAP server doesn’t have to deal with filesystem mount points, shell accounts, Windows security domains, or any of the many other things that make ActiveDirectory and OpenDirectory so complex. Instead, the LDAP server is primarily for keeping track of logins for the various website: this blog uses it, as does the wiki. This means we’re free to use a fairly simple schema.

For users, we’re using inetOrgPerson, which requires very few fields (only cn and sn), but allows many fields for identifying people. We also use the userPassword attribute to store hashed passwords, which apps check by attempting to bind to (log into) the LDAP server as that person. Groups of users are implemented as groupOfNames entries, which are barely more than a DN and a list of member DNs.

All of these structures are very simple and well-understood: inetOrgPerson and its parent classes define the attributes every address book application expects to find in LDAP address books, so the LDAP server could (were it public) be used as a Hacklab address book.

Integrating apps into LDAP was mostly very straightforward, but different apps have different ideas of what “integrated” actually means. Trac, out of the box, trusts whatever identity Apache passes it but handles authority roles internally. The plugin for pulling roles from LDAP hasn’t been updated in approximately forever, and doesn’t work with Trac 0.11. So, Trac roles are managed by Trac, and Apache only checks whether users are allowed to access Trac at all (and presents the login box). WordPress’s wpDirAuth plugin doesn’t handle role management at all, so WordPress also manages privileges itself, relying on LDAP for logins. WordPress also talks directly to LDAP, rather than using Apache’s LDAP integration.

The only real snag is user management, and I still haven’t found a good tool that doesn’t assume you’re running an enterprise with hundreds of users. The password page is a PHP script I found while googling around that I vetted for security and installed, but for actually creating new users I’ve been relying on LDAP Browser, which isn’t so much a user management tool as it is a generic LDAP query tool. Combined with some custom templates, it works, but it’s not hugely comfortable.

Using LDAP is not a magic bullet for centralizing identity data. However, it’s cut down on my own admin overhead for trac and the wiki, and it makes life easier for hacklab members by reducing the number of passwords they need to remember. I think it’s a net win.

We spent a lot of time getting things like a net connection, insurance, two-factor door authentication, and a monitored alarm system set up.  But in the end, incorporation was about the most stressful thing to get going, and we’re not through the process yet.

Obligatory not-a-lawyer preface:  I’m not a lawyer, I was simply raised by a pack of them.  I can read forms and websites, but this should in no way constitute legal advice.  Do your own research and consult a good lawyer – it will save you hassle in the long run.  If this post kicks your puppy or causes your hacker space to burst into flames, please complain elsewhere.

Incorporating a non-profit in Ontario isn’t a huge deal, or particularly expensive.  It’s $155 and a 4-page form, plus a corporate name search (NUANS search), which costs around $35.  We expedited ours for $100 to get 7-day service, and it ended up taking 4 business days – way awesome compared to 6 weeks for the normal fee.

The Ministry of the Attorney General has a really excellent guide to incorporating non-profits up on their site.  Read the whole thing.  The form you need to fill out is in the appendix.

The one thing I wish the guide had been clearer on is that for a non-charity non-profit, which is what we are, you don’t need to have your corporate objects approved.  That’s just for charities.  Phew, we don’t have to pretend we’re a club….

But wait, we kinda did.  They didn’t like our name!  HackLab Toronto Inc.  Sounds too for-profit, apparently.  So it’s HackLab Toronto Club Inc.  Which is way too wordy for my tastes, but I really don’t care enough to be concerned.  So yeah, make sure your name sounds non-profitey in a way that is consistent with your corporate objects, which you will learn all about when you read the handbook.

Here’s what we ended up coming up with.  It’s suitably vague-yet-specific, but in retrospect I can see how the person doing the filing thought we should have “club” in our name.  These are the “objects for which the corporation is incorporated” to use the official Ministry lingo:

Hacker Club: The establishment and operation of a social club for individuals interested in computer security, technology, electronics, and related topics for the purpose of:

* providing facilities and equipment for the pleasure and accommodation of members and guests;

* sharing information and knowledge for the mutual benefit of the members;

* organizing technical, educational, and social events;

* promoting awareness of privacy and digital rights issues affecting members and civil society;

and such other complementary purposes not inconsistent with these objects.

For the special provisions, we just left it at the default which comes pre-printed on the form.  You should consult a lawyer to see if that’s what you need to do to.

I got the NUANS search done here, and they took about 18 hours to get it back to me.  Make sure you get a full NUANS, not just a pre-search.  Also, you can do pre-searches for free on the federal NUANS site – just let your session time out if you use up your 8 free ones.

The other board members and I are working on our Bylaws, which for Ontario corporations are not approved by any government agency, just kept internally.  Ontario corporations are kinda great that way.

Tomorrow I’m going by the office to pick up our Letters Patent, and then we’re all set to get a bank account, which is pretty much our last step in becoming all official and stuff. Except registering for PST / GST… but more on that later.

-Leigh