Continuing with our profiling of new Community Toolboxes, we move on to Amanda Hickman‘s Recycle-A-Bicycle Toolbox.
Amanda is a consultant in Brooklyn, NY. She also directs communications at Recycle-A-Bicycle, for whom she created this toolbox. I recently chatted with her over email.
SSC: What is Recycle-A-Bicycle?
Amanda: RAB is a youth environmental education and job training program in NYC. We run bike shops in city schools where junior high kids can learn to repair bicycles. We also operate two storefronts where we sell used bikes. My position there is part-time and encompasses everything from writing a monthly newsletter and working with young interns to maintaining our ICT infrastructure.
I think that our basic limitations are consistent with a lot of other small, low-budget organizations out there: we don’t have money for software licenses or tech support, but we need the convenience and reliability of a stable network. So I hope that other folks can look at what I put together at RAB and try out that combination in their own organization.
SSC: Why did you create this toolbox?
Amanda: I think the short answer to why I created it was that I wanted to break out my toolbox a little bit. I don’t actually use QuickBooks Point of Sale, but it is part of the infrastructure at Recycle-A-Bicycle. I think that is true for most tech consultants, and probably for a lot of non-tech folks, and non-consultant techies. I have a handful of different projects going and some of those projects are using software that I wouldn’t say make up “my” personal toolbox.
At NOSI, we’ve been talking about doing a “desktop project” — starting with identifying a diverse and representative array of non-profit workers and looking at what each person is actually using on their desktops, with an eye towards helping free software activists assess (realistically) the potential for free software to meet the day-to-day needs of staffers at non-profit organizations.The RAB toolbox isn’t just my desktop (clearly) but it is the beginning of my effort to document the tools that we are using in one concrete organization. We use a bit of free software, but we also chose some non-free applications in a few cases.
SSC: Obviously, RAB’s budget requires the use of a lot of free software. What other factors drove your decision making for choosing the tools you did?
Amanda: Politically, I think it is very important to use free software: I see our work as part of a movement to build a national network of community based cycling centers and youth bike programs. Access to basic infrastructure tools is a key piece of any project like ours, and by using free tools, we’re contributing to infrastructure that makes those same tools more accessible to other organizations that want to build on our experiences.
For the most part, I chose free software where it did what we needed to do and where there was enough of a community that I felt like I could get support. Where I didn’t have the support infrastructure in place, or where staff insisted on a proprietary alternative, I didn’t argue too much.
SSC: What do you like about the tools you chose?
Amanda: I really like Ubuntu as a desktop and since we’ve got a tiny network, it made sense to run my workstation as a SAMBA server. BackupNinja handles automatic backups every night and we know we can take advantage of security upgrades without having to pay new license fees.
We use OpenOffice on my workstation but the Director was more comfortable in MS Word so she went ahead and bought an MS Office site license. Since we’re getting ready to do a big mailing, I’m glad we’ve got access to MS Office — OOo’s mailmerge functionality is seriously wanting at this stage.
I really like Thunderbird as a mail client–the spam filtering works really well and it is consistent across platforms. It also does a much better job than Outlook at stopping malware.
Calcium isn’t free software, but it is free (as in beer) and it is clean and it works. I needed something that wouldn’t confuse people, as I really needed everyone to be using the calendar. It was absolute chaos before I set up the calendar. Every week, there’d be mad scrambles to sort out why the interns went to Brooklyn where there wasn’t a teacher waiting for them or how we’d scheduled two different groups to use the ride club fleet. Mechanics would tell a manager they were going on vacation and still end up on the schedule because it wasn’t written on the wall. Or they’d write it on the wall and no one would notice because they hadn’t told anyone. It was silly. For extra fun, we run shops in five schools, and we’ve got three other sites around the city, so people desperately needed to be able to look at a single calendar. A few weeks ago, I overheard a new manager saying “well, I looked at the calendar from last year and we had x mechanics scheduled every day starting in May” and I knew the calendar had been a success.
Quickbooks Point of Sale wasn’t my project–the Director desperately wanted to eliminate the volumes of paper we were generating and the massive amounts of data entry. We were already using Quickbooks, which was one vote in favor of going with their POS setup. I looked for free and open source systems, but in the end, our bookkeeper and our accountant know Quickbooks and were willing to help us set it up, so we went with it.
Emma is another proprietary service we decided to use–an old staffer had the chance to nominate us for a year of Emma free of charge and we figured it was worth a shot. I don’t know that we really have the wherewithal to do much with the data we get back from Emma about who is opening the newsletter and who is ignoring it, but it is neat to see.
Drupal was an easy choice–I know Drupal well. When I started, we had a funky website that had never quite worked. We needed to rebuild it and needed to be able to accomodate rotating interns and apprentices working on the site. Almost any CMS probably would have worked. One of my interns recently asked about Drupal, though, because he wants to set up a site of his own — it was nice to be able to tell him that if he was willing to ask a lot of questions and set it up he wouldn’t have to pay for software to use Drupal. Since he’s sixteen and doesn’t have his own computer, that makes a big difference.
The CiviCRM story sounds a lot like the calendar story: staff spread all over, notes on the wall. We started by storing basic contacts there for staff who needed access to the rolodex from outside the office, but the new Director has really taken to it and we’re starting to consolidate a lot of contact information there. Just having a basic place where we can keep track of folks who offer to volunteer (someplace outside of the Director’s head!) has been huge, and newer staff don’t even think twice about looking up information they need there.
Flickr and MySpace (I should add that to the toolbox, I guess) are more community tools. We work with Jr. High and High School kids. They certainly aren’t free (as in freedom), but I’ve never had to explain how to use either one.
SSC: Is there anything in that you wish did a better job?
Amanda: I wish we could sync logins across mediawiki, Calcium and Drupal. I wish that Open Office could handle the kinds of mail merge that we need to do. I wish that QuickBooks Point of Sale, Emma and CiviCRM could talk to each other so that we could manage donor data in a single place. We exported all our email info to Emma but that lives outside of the database now.
Thanks Amanda! That certainly is a wealth of information, and we hope it’s helpful to other organizations in similar circumstances as Recycle-A-Bicycle.
Thanks for all the interesting leads, Amanda!
I’m a little concerned that Calcium does not appear to be free software by any definition of the term, since the no-fee demo is only valid for 30 days.
At some point, i’d love to get into syncing logins across multiple applications. I have some good ideas about how to do this, but i don’t know the individual tools well enough to know if they’ll work. My basic approach is to coax each webapp to accept the webserver’s identification of the connecting user. With any of apache’s mod_auth_* modules, you can usually coax this info into the $REMOTE_USER environment variable, for example. The different modules provide authentication against standard htpasswd files, system-specific PAM, kerberos domains, LDAP, or many other options.
The advantage of this approach is that each webapp gets the full flexibility of the web server’s authentication methods without worrying about implementing/maintaining these methods themselves. trac is an example of a webapp that uses this model well.
Thanks for all the interesting leads, Amanda!
I’m a little concerned that Calcium does not appear to be free software by any definition of the term, since the no-fee demo is only valid for 30 days.
At some point, i’d love to get into syncing logins across multiple applications. I have some good ideas about how to do this, but i don’t know the individual tools well enough to know if they’ll work. My basic approach is to coax each webapp to accept the webserver’s identification of the connecting user. With any of apache’s mod_auth_* modules, you can usually coax this info into the $REMOTE_USER environment variable, for example. The different modules provide authentication against standard htpasswd files, system-specific PAM, kerberos domains, LDAP, or many other options.
The advantage of this approach is that each webapp gets the full flexibility of the web server’s authentication methods without worrying about implementing/maintaining these methods themselves. trac is an example of a webapp that uses this model well.