[hackerspaces] RFC: Hackerspace in a Box

Kive kive at kive.me
Wed Nov 18 07:14:39 CET 2009

Along the lines of the Hackathon happening this weekend, several of us are
considering tackling this idea of a "Hackerspace in a Box". Not my concept,
but I'm afraid I don't know who in the Southeast US what I heard of
originated from many months ago.

I hope I'm not stepping on many toes here...

In my view, this includes:

 - membership tracking system
 - API and sample plugins for provisioning, deprovisioning, and
reprovisioning services (security badges, e-mail accounts, whatever)
 - member account management portal
 - API and plug-ins for payment gateways (google payments, paypal, etc...)
to handle dues and donations
 - API and Android application for member account management
 - simple accounting system (as simple and automated as possible)
 - high level of customization decoupled from core applications (simplified
upgrades, ability to turn stuff off so you can use existing things like
wikis, mailing lists, etc...)
 - reporting (mostly financial)

The idea here is to bootstrap Hackerspaces. It'd be ideal if we can build a
system that existing spaces may also use -- which requires a lot of
decoupling, customization ability, and an overall competent build, and then
to have the hackerspace community continually build it.

The idea here is NOT to force anyone to replace any working systems. Use
this when you have no working system. Use this when you have a poorly
working system.

In the spirit of this, I'd like for folks to start indicating interest if
they'd like to take a leadership position, or are capable of being a
principal developer (with other people probably working on smaller pieces as
directed by them, and learning in the process).

I'd like to break this into five chunks, with some overlap when it comes to
the API's:

1) Core System (the open-source applications and integration)
2) Customization, look, feel, gui (make it work, make it pretty)
3) Plug-In APIs (make it easy for people to create additional plugins for
provisioning, etc... and sample plugins for common services)
4) Mobile API (hooks for android, iphone, etc... apps)
5) Android (first mobile client)

I can use:

 - project managers/project leaders
 - lead developers for each area
 - volunteers for each area (working for the lead dev, and learning is okay)
 - folks with understandings of the API's for international payment systems
 - treasurers for spaces, or those with financial responsibility (I want to
throw you on a mailing list to go over accounting systems, reporting,
 - Folks that actually work for Google as Android Subject Matter Experts,
willing to lend assistance. Likewise for Apple or Microsoft, if available,
we may take advantage of those opportunities.

Languages will depend on the systems being implemented. Android speaks for
itself. Most web components will use php, css, etc... The rest is up to the

I will create an overall project plan defining a starting place for
requirements/capabilities. A blueprint, if you will.

We'll want leads to be able to communicate, if possible, sometime on
Thursday/early Friday, to make sure we're on the same page.


I'd love to hear comments from all of those in the community. In particular,
I'd like to know if:

 - You have ideas, requirements, etc...
 - You are already working on something similar, and whether or not we
should consider using part of that code, or helping to complete your own.
 - You have already completed this code, or part of this.
 - You have very qualified recommendations of what package to use for any
given piece (or anything you'd like to see be a piece of this) -- please be
sure to qualify your recommendation with regards to competing

All comments welcome -- feel free to reply to me individually, or on the
thread. I also encourage you to forward this to your own space mailing
lists. In particular, I'd love to get as many treasurer eyeballs on the
blueprint as possible, once I'm done writing it (Thursday).

I'm hoping this will move quickly. If enough resources don't appear, we'll
have to reassess which pieces we -can- reasonably accomplish, or push this
off to happen at a later date.

-kive (Freeside Atlanta)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hackerspaces.org/pipermail/discuss/attachments/20091118/598e34ab/attachment.html>

More information about the Discuss mailing list