Starting a local Ruby group
Ruby-NYC held its first meeting in February 2004, in the conference room of the New Museum of Contemporary Art. Three people showed up, including myself. Back then, the world of Ruby was much smaller: Rails was but a twinkle in DHH’s eye, and the RubyConf I had attended the previous October was only around 40 people. Two-and-a-half years later, we have up to that many people showing up to our local meetings. I’m not sure if I can take any credit for it, but it’s fair to say that Ruby-NYC is a successful Ruby group.
During one of the dinners at this year’s RubyConf, I sat with two guys from northern Utah who asked me for tips on starting their own local Ruby group. It occurred to me that my experience of helping run Ruby-NYC might be useful to others—so below, for your consideration, please find my obsessively detailed tips on how you might start your own local Ruby group.
Starting a group like this is easy enough: It just requires a few organizational details and a bit of busywork. You need a mailing list and an accompanying website—we use Yahoo! Groups, which I like because it’s got other features like a calendar and a survey tool. Some people like to add a blog aggregator or their own custom web stuff; that’s cool but the most important things are
- an email list so group members can talk to each other
- a website that group members can go to and find the next meeting date
- a website that will show up when Rubyists who don’t know about your group do a Google search for, say, “Northern Utah Ruby”.
You also need a venue, but if you’re just starting out you might only have 5 people show up, so that makes finding a venue easy. Anywhere with seats will work, and it’s nice to have WiFi and electrical sockets. This can be a conference room at somebody’s office, or a coffeeshop, or even somebody’s house. Some folks like to meet at bars or restaurants, but I personally think that’s less-than-ideal because you might not have the sort of space or seating that would allow two people to sit side-by-side looking at code on a laptop. (We do encourage people to bring beer to our meetings, though. So far, we’ve been lucky enough to avoid any drunken vi-vs.-emacs brawls.)
It’s good to set a regular schedule early on, so people can schedule your group meeting into their lives. Personally I think once a month is good when you’re starting out: You want it to be a regular part of people’s lives, but not so often that it feels like you’re trying to start a cult. Ask for opinions on the mailing list—this is a good use for that silly survey tool on Yahoo! Groups—and then set a schedule like “the third Wednesday of the month”.
After you’ve had a meeting—more on that below—you send out an email to the list, thanking folks for coming and giving a quick recap of what happened, even if all you did was hang out and kvetch about your boss. (Some discretion may be required, of course.) This is particularly important at the beginning, so people who didn’t go can be reminded of the cool thing that they missed, and that this is not just some thing that’s going to fizzle out in a few months. Eventually you’ll probably stop doing this; I don’t do it for Ruby-NYC anymore.
A few extras that are easy to add:
- Starting an IRC room for your group on freenode is an easy way to add to a persistent sense of community, and will be a godsend to those members who are really into the idea of your group but can never attend, whether due to volunteering at a soup kitchen or Lamaze classes with their wives or some other entirely selfish scheduling conflict.
- O’Reilly has a free user group program: We signed up and they’ve been sending us piles of free books. The expectation is that whoever gets said books will post a quick review somewhere, and although we’ve been slack on this we’re going to start raffling them away for free at our next meeting.
What happens when people show up
So what actually goes on at these meetings? At first, you might not need to structure it at all, since people will be meeting one another and that can be plenty interesting. It’s probably sufficient to have people go around in a circle and talk about what they do, their interest in Ruby, etc. Yes, it’s mildly awkward, and you’ll get a few Alcoholics Anonymous jokes, but it works fine. Just getting a few programmers together to talk shop, that can be an hour or two right there.
By your second or third meeting you’ll probably need something more structured. We do talks. These can be five minutes, or they can be an hour, but no matter what they’re not going to be formal. I always emphasize that you don’t have to be an expert, or talking about some insanely difficult library you’ve been writing furiously for the last two years. This ain’t RubyConf. It can be enough to just talk about a project you’ve been working on recently, or even just what you learned when you had to investigate a specific area, such as web services or integrating with Microsoft Excel.
Still, these talks probably won’t materialize on their own, and when a group is starting one of your primary duties as an organizer is to drum them up. This is mostly a matter of pestering the mailing list until somebody breaks down and agrees to do one. Also, it’s helpful to keep this in the back of your mind while chatting with other members, so you can recognize when people are pursuing specific topics that would be good for a talk: “Hey Rob, you seem to really be spending a lot of time with Scriptaculous, care to talk about it next month?”
Another nice thing about being small as that you don’t need much in the way of equipment to support a talk. I’d say with a group of up to 8, you can get by with the “over the shoulder” method: That is, one person gives the presentation right on his laptop with others sitting next to him or standing behind him.
A lot of people ask about doing projects as part of the group, but that’s not something we’ve ever done. Sure, we’ve got plenty of members with their own projects. Zed Shaw wrote most of Mongrel while he was a New Yorker, and we’ve got Locomotive’s Ryan Rauum and SpecUnit’s Trotter Cashion. Greg Brown of Ruport fame doesn’t even live in NYC but he comes down as often as anybody else.
And yet people don’t work on these projects much at our meetings, and there’s not a lot of project collaboration happening within our group. It may be because anybody who wants to be involved in an extracurricular project is already involved in one or two or three. (This factor may be NYC-specific.) It may also be because a lot of people don’t want to come to a user’s group if there’s any sense of obligation—they’ve already got a job, after all.
It took Ruby-NYC more than a year to have 10 people show up to a meeting, but it’s quite possible that your Ruby group will grow more quickly than that. As with anything, scaling brings its own challenges, but they’re quite manageable.
The biggest one is getting a dedicated space, which might be necessary once you start topping 10 or 15. Your best be is probably to look for a local tech company that has a conference room to spare. There’s no secret to this, really: You just nicely ask every company that comes to mind. Remember that good programmers of any kind are hard to find, so many companies are happy to support something like this. In our case, we’re hosted by Bway.net, a cool independent ISP which also hosts NYC Wireless.
As your group grows, you’ll also need a projector for presentations. A good projector is expensive, so it’s best to avoid buying one if you can. If you can find some company to buy it for you in return for a sponsorship of some kind, that’s great. Or maybe you can find a local company, like a Rails shop, that’d be happy to split the purchase with the group. In our case, Bway has a projector that we rent for a nominal fee.
If the group gets really big, or your space is noisy—like if there’s an older air conditioning unit that’s on in the summer—you might need a mini-P.A., but these aren’t as expensive as a projector. I bought us a portable P.A. and wireless microphone: The wireless mic comes in handy since you can pass it around if there’s a lot of discussion at the end of a talk. It’s not a trivial expense, but since I bought it, I’ve been passing the hat every meeting and slowly getting my money back in donations.
As the group grows, you may want to meet twice a month or even every week—we meet twice a month, with the first meeting of the month being an unstructured “hackfest” and the last meeting more structured, with talks and an agenda and all that. And don’t forget name tags. They’re unbelievably dorky, but it’s a lot easier for people to get to know each other when they’re not wrestling with embarrassment about forgetting one another’s names.
Or, not growing
On the other hand, maybe your group will stay small. Ruby will probably keep growing for a while, but in some places you’ll run into basic demographic limits. So you might be asking yourself: If it stays small, is it worth the trouble?
I’d say that it is. Now that Ruby-NYC is fairly big, I enjoy helping to organize it, but I enjoyed it when it was small, too. Before we needed a projector and had speakers popping in from other cities, I was still meeting all sorts of interesting people, and getting into lots of thought-provoking discussions once a month.
And in our field, that sort of regular contact can be hard to come by. Software engineering can be a fascinating, rewarding field, but with all the things programmers have to put up with—poor management, unrealistic deadlines, uninspiring business decisions—it can also be frustrating and isolating. But if you’re in it for the long haul, if software is what you do, then you’re going to have to figure out how to enjoy it, how to not burn out, and even how to take pride in the code that you commit.
Maybe you’re lucky, and you already have a group of folks that you can talk about these things with. But if you don’t, that’s not going to change. Not unless somebody comes along and changes it. And who knows? Maybe that somebody is you.