As I had mentioned last week, I went to the Ohio LinuxFest. I was generously rewarded not only by the presentations, but also by the luminary class event as a whole. Friday’s keynote speaker was none other than Jon Hall. Jon spoke about how Linux is used around the world. Two key things I loved about this talk was how Jon Described his interaction with Linus Torvalds and how Jon was able to get Linus a DEC Alpha so that Linus could port Linux to that platform.

As well, I greatly appreciated the tale of how Jon had left a Linux CD behind at the University of the Pacific on Fiji. On his next visit there, Linux ruled the installed environment. There was of course more, but suffice it to say, it was an engaging talk.

On Saturday, Dr. Kirk Marshall McKusick gave a talk on how to manage a project. He used the BSD / FreeBSD projects as the basis for this talk. One of the keys to running a successful project, Dr. McKusick suggests, is getting rid of the deadwood. In the case of the BSD project, he did this by ensuring that there was a core team that changes on a regular basis; members to the core team, who can grant commit privileges and are elected by the committers. It seems an excellent model for project organization.

I saw other presentations that I valued. Of note was the presentation given by Emma Marshall from System 76 about how she works with a team to help get Ubuntu into classrooms. I also learned a little about how Juju is used to help deploy in a server environment by Jorge Castro. I was interviewed by the Sunday Morning Linux Review crew. I show up at about the 58 minute mark.

If you’ve never been to OLF, I recommend you put it on your conference calendar for next year and that you take a friend.

Daniel Hinojosa, SourceForge Community Manager

While this tool is an excellent way for a team to pick a place to go to lunch, this module could easily be used for “ranked choice” voting like what Alameda County in California uses.

To learn more about this Perl module, check out the PrefVote.org page.

Daniel Hinojosa.

We started because I was tired of watching family and friends roll their eyes when I would try to show them something cool in Ruby. We started it back in 2005 when I finally tried and really discovered Ruby. I had seen it before and did not take it seriously. As I got into it more and more, I couldn’t get enough of it. During that time there was a site gaining popularity called 43 things. I found about a dozen people in the area who listed ‘learn Ruby’ or ‘learn Ruby on Rails’ as things they wanted to do. I reached out to them and setup our first meeting over lunch. After that we scheduled our first night time meeting. We have been meeting every single month ever since.

Amazingly enough, one of the original 6 that showed up to that first meeting is now my business partner at EdgeCase. Funny how life works out that way.

We now have 450 members on our mailing list. The group averages about 35-40 per meeting. We have gone as high as 90 (we brought in Uncle Bob to speak once) and our lows hover around 20-30 now (holiday weeks, etc).

We now have two meetings a month. One meeting is an eyes-front lecture meeting and the other more of a code jam / hackfest. We have tried to balance long talks (30-45 minutes) with a few shorter 5 minute lightning talks. We have a couple people doing regular sessions each month called ‘method of the month’ where we go through some particular method from the standard library in detail. Pretty interesting really. Lately we have also had a person leading what he calls the CRB labs. These are more detailed lab exercises that help everyone learn more about Ruby by trying it.

Photo courtesy Aaron Christy

Every few months we try and bring in a speaker from outside. We have had quite a few people come and talk to us about a wide-range of topics that all share a common theme: passion for technology. While we are a Ruby group, having people from the outside to talk about fear of failure or technical writing has helped us prevent typical tunnel vision that many groups experience.

Code Jams are pretty open format. Usually a couple people have things they want to work on and are looking for a pair. The others are along for the ride to either pair up, or find some kind of lab exercise to work on with someone. All of these encourage pairing and collaboration and learning from each other.

That is an interesting question. I would say they fall under a couple categories: consistency and helping beginners.

When we first formed we had trouble securing a venue on a permanent basis. We found that we would build a decent following (any more than 30 a meeting we were really excited about) and would then have to change venue or change the day. Every time we changed, it would introduce a massive dip in attendance. We now have a day that we will not compromise on (third monday of every month) and a very regular venue. When you first form though, these are the hardest things to nail down.

The other major problem that creeps up about every year or two is the problem with helping beginners. There is a tendency with user groups to forget that you have people that have not been using the language or framework as long as you have. You hesitate to recycle talks because people have talked about it already or seen it. So you inadvertently create a group of people who are advancing, while new members are left in the dust. We now strive to make sure we revisit certain talks, or topics. We try and balance beginning and advanced talks so that we can keep it interesting for our long time members, but also encourage new blood.

Photo courtesy Aaron Christy

We have been migrating away from talks that are only about Ruby. The group has migrated into a group of those passionate about software development in general. Many of our talks lately have been focused on the craft of software and are not as technology specific. We will more than likely keep this up. We also have some national speakers who have agreed to come and speak this year, so we will have some very exciting meetings in the coming year.

Stay consistent in day. If possible, find a venue that you can continue using for a long time. Feed your users. A little bit of pizza goes a long way to making sure people attend. Don’t forget new users. User groups are for those curious about a language or platform to come and check it out. Make sure you have content they can understand and enjoy as well. Finally, make sure to have fun. User groups are for those that are looking for an outlet for their passions. Maintain that. Find a watering hole nearby your venue and adjourn there after the meeting is over. I’ve been to way too many user groups here in town that are stiff, lifeless and where everyone races for the door when the meeting is over.

——

Thanks, Joe!
If you are a Ruby dev in the Columbus, Ohio, area, I encourage you to reach out to Joe and the group at http://columbusrb.com. I can personally attest to their level of awesome, and they clearly have some great stuff planned for the group in 2011!

This week, I reached out to my friends at the aptly named AtlantaPHP, a PHP users group in Atlanta, Georgia. Chris Spruck and Kevin Roberts are the current organizers of this group, and they were kind enough to answer a few questions for me.

In March 2004, Ben Ramsey and Matt Kern discussed forming a PHP user group and ultimately merged with a previous Meetup.com group that had had a few meetings. We had a few informal meetups and planning discussions with half a dozen people or so, and as word spread, things became a bit more organized. Based on mailing list archives, the first real meeting was in November 2004 and except for a few rare cases like a weather emergency, the group has met every month since then. Ben and Matt have since moved away from Atlanta, but we have a terrific core group and things are going strong. Special thanks to Ben Ramsey!

We average 30-35 people at our meetings, but we have 300 on our discussion list and just short of 500 people on Meetup.com.

We start by showing a quick set of slides that mentions some PHP community resources for new people like PHP news sites, IRC channels and so forth, as well as any upcoming events in our area and local, regional, or international conferences. We sometimes have a short session before our main speaker, such as demoing a PHP-friendly IDE or other useful tools or talking about some “quick tips”. We ask if anyone is hiring or looking for work, then after the preliminaries, we have the main speaker for an hour or so. We then go to a nearby restaurant for dinner, drinks and socializing – which many have said is better than the meeting!

The Atlanta PHP Crowd

I don’t think we’ve encountered anything we’d call an obstacle, but the toughest thing we have to do is find a speaker every month and try to balance things for all experience levels. We realize we can’t be all things to all people every month, so we do our best to mix things up. One funny blip in our history – we were meeting years ago at an IT training and testing center and when we arrived for a meeting, we found the place basically boarded up and shut down. Our contact had forgotten to let us know of the closure until right before the meeting time, so we went to the nearest pizza place and by the next month, we had a new location.

We’ve always wanted to help provide educational opportunities for our members and the technology community and we just had a free, member-led “Intro to the CodeIgniter Framework” half-day workshop, which was really successful, so we plan to continue to do more things like that. We take pride in that we’ve never charged members for dues or expenses, but we’ve realized that running a group on no budget or on the limited pockets of a few generous people can be restricting, so we’re gearing up for the ability to take donations and sponsorships to allow us a bit more freedom to provide resources to our community of members. We’d also like to work more with other local technology groups on special events, cross-training and so on.

Stick with it! If your group is new or small, it will still be a valuable resource to people and it will grow eventually. Don’t be discouraged – groups take time to develop and evolve, so give things a chance.

Delegate! Put together a few trusted people to help you. You can do everything yourself, but it’s easy to get bogged down and lose your enjoyment.

Experiment! Talk to your members and find out what they want from a user group. Try new things and different formats and see what works. Don’t be afraid to change it up. Caveat: try to keep a consistent meeting time and location. Make it easy for people to remember where and when you meet.

Network! Attend other similar groups and talk to other leaders to get ideas and see what works for them. Look for events specifically for user group leaders like http://neugls2010.pbworks.com/ or http://seugls.pbworks.com/ – or plan one yourself! (Disclaimer – I’m a co-organizer of SEUGLS.)

——

Thanks Chris and Kevin! If you’re a PHP developer in the Atlanta area, you are highly encouraged to check out this fun and welcoming group.