We have a demo of the CampFireManager over here: http://demo1.campfiremanager.info
CampFireManager is a talk scheduling tool for conferences - such as barcamps or fixed schedule conferences. In it's usual deployment, it sorts talks into rooms, based on the number of attendees attending a talk. Shortly before each talk is due to start, the location of each talk is locked, and that location is broadcast, both to Twitter and Joind.in. Plugins are planned (and in some cases, have worked in the past!) to also broadcast that content over SMS (using Gammu), IRC and XMPP. As part of the association with Joind.in, talks are encouraged to be voted upon to give feedback on the event to presenters and organisers.
CampFireManager is on it's fourth iteration. We currently recommend CFM2.
- The original CampFireManager (cfm) was a sensible origin for this software. It was based on the premise that all attendees would have only mobile connectivity, and a few stand-alone terminals. In it, you will see the various underpinnings of the rest of the versions. It was used at OggCamp '11, after cfm-l showed that CampFireManager was a good fit for this conference. It was also used at the first UCubed. It was born on 13th January, 2010.
- CampFireManager-Lite (cfm-l) was an attempt to provide more of a static-event template to CampFireManager. It was written after the beginnings of the original CampFireManager were started, and was used at OggCamp '10. It is very poorly written, and was done in a hurry to match a timescale. It was born on 13th April 2010.
- CFM2 (CampFireManager Version 2) was a major re-write of cfm, using classes. It is the current stable version, and was used at OggCamp '12 and is planned to be used at OggCamp '13 and is where the current development focus is. It uses Smarty and jQueryMobile to render on smart phones and desktops. It was born 24th January 2012.
- CFM3 (CampFireManager 3) is our next development target, and moves the focus of the site from being a rendered site to providing a stable JSON, RESTful API on which a frontend will be deployed. We hope to consider using this at OggCamp '14, but this relies on it providing either a better API, a more consistent interface or more features than CFM2. It was born 27th March 2013.