A membership management system for Baltimore Node
JavaScript Ruby
Switch branches/tags
Nothing to show
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.



Nodewise is a web-application for managing Baltimore Node and other organizations like it. We are a self-organizing collection of tech oriented folks whose interests have aligned long enough to collect a membership fee, rent a work shop, and vote on things.

See our door project notes at: http://wiki.baltimorenode.org/index.php?title=RFID_door_lock.

This project is inspired in part by the Open Door Hackathon, but is not intended as serious competion.


A hackerspace membership system should present the members as the most important part of the organization. The space comes second and third are all the administrative details. Things like money, inventory, and schedule may be considered part of the space but are probably administrative details.

I. Members

  • Information they want to make public, stuff that's okay to be connected to the outside world. Outward facing: as little or as much as the member decides.
  • Inward facing: control of their membership, information about their dues, access to basic contact info for other members.
  • Dues Information System - organizing information about schedules and status so financial officer can tell who's overdue and members can check on their own payment history.
  • Voting Management System - we do a lot of voting on the mailing list these days, it makes sense to bring it into this application since we'll have a better handle on history and be able to better control the process. Plus, maybe we can play with some totally sweet voting algorithms.

II. The Space

  • Workshop control: access control (as it concerns the space) and environment (lights, temperature).
  • Workshop information: Pachube feeds, X10, webcam, etc.

III. Administrivia

  • This is mostly money focused.
  • This is the secure inner functionality, the stuff no one on the outside should have access to.
  • Only the treasurer should have the ability to modify the money area.
  • This area could also include living membership documents such as: bylaws, meeting notes, calendars, and a web-based storefront.

This stuff is relegated to third place since this area of the application seems open-ended enough to provide a lot of "you know what you should do..." and "somebody should..." moments. Anything that could be considered feature bloat should be shoved under the heading of administrivia and ignored until the urge passes.

Other Stuff


You'll need ruby, at least 1.8.7. I'd also highly recommend rvm.

Once you've downloaded the source, run bundle install and cp config/database.local.yml config/database.yml.

Once those are setup and ready to go, you should be able to run the tests and a local server.

If you want to deploy to the Node's servers (Heroku: demo, staging, production), contact me to be added to the heroku projects as a collaborator.

If you want to fork the project and run it for your own hackerspace, more power to you. I recommend waiting until I finish.

Running your own instance

This is bog standard Heroku compliant code.

I'm running on a free instance using free versions of the Sendwise, Cron, and Custom Domain Heroku addons.

If you want to install and maintain your own instance:

  1. clone this repo
  2. modify config/heroku.yml to include the appropriate heroku app names
  3. $ bundle install
  4. $ rake heroku:create
  5. $ heroku config:add EXECEPTION_RECIPIENTS=an.email@address.co
  6. and away you go


Just Use It