Starting a User Group

Posted by Gavin Doughtie Sun, 15 Jan 2006 05:12:00 GMT

At RubyConf I stood up and volunteered expertise I accumulated starting and running the Los Angeles Java Users' Group for the first seven or so years of its existence. If you're thinking of starting a group in your area, here are a few tips:

Why a User Group?

It's really easy to mistake the fluid and personal-feeling communication tools available these days for real face-to-face time. Brains are amazing things, with machinery that has evolved specifically to help us communicate with each other in person. Don't miss out on it!

Get a bunch of people interested in the same thing together in a room, stir the pot with an interesting speaker or shared project, and then give folks a chance to talk informally with each other afterwards.

The rewards are immediate AND long term.

The Basics -- What Do I Need to Have a Users Group?

  • Users

    Sounds obvious, but these groups form around people using something, usually a technology. You'll need to go out and find people who are interested. For the LAJUG, I started out with co-workers and friends and my first meeting had... three people present, including me.

    I spent the next month attending other meetings in the area -- multimedia design meetings, other programming groups -- and promoting the next LAJUG meeting. The second meeting had about twenty people, and afterwards there were usually at least that many, sometimes quite a few more.

  • A Regular Time and Place

    LAJUG benefitted immensely from being held with great regularity on "The First Tuesday of the Month from 7:00 to 9:00 PM." The venue changed every couple of years (it met at Enfish, ISI, Hughes, Caltech, UCLA, Goto/Overture and now Sun), but it was pretty easy for attendees to mark their calendars with a recurring "LAJUG" event.

    Settling into a regular time and place also helps make the group feel "stable" and attract assistance long-term

What Facilities Do I Need?

  • Free

    What became a running theme with LAJUG was a certain "open source" quality. Unknown to me, Michael Merle had attempted to create a Java users' group a few months before I did. However, he chose to have his first meeting at the venerable Electronic Cafe in Santa Monica. This required him to charge admission to pay for the facility. Paying, even a token amount to a worthy venue, added enough friction to that initial attempt that there was no ongoing group when I started the organization that still meets regularly today.

  • Large enough for the group to be comfortable.
  • Close enough to the middle of things that most members don't have to go terribly out of their way to get there.
  • Provides an LCD projector so presenters only have to bring their laptops (not strictly necessary, but always helpful).

Getting Sponsored

No! In the seven years I ran LAJUG, I never spent or took in money. People volunteered space, an email list and a web server, and that was all it really took. These days, the web space and email lists could be handled through any one of several advertising-sponsored web sites. (Feel free to link to your favorites in your comments to this post.) During the boom sometimes vendors would spring for pizza and soda, and I sometimes brought coffee and cookies myself. Later on, I got members to volunteer for cookie duty.

Getting Speakers

The best speakers come from within the local community. If you're active on the ruby lists and IRC you can probably find them there, and it wouldn't hurt to email the people you'd like to present *now* for possible engagements "whenever they're in your area". I've never needed to pay anybody -- the non-vendors want to give back to the community and promote themsleves, and the vendors, of course, want to sell you something.

Preparing Speakers

Over any stretch of time you can count on a the following:

  • Your speaker has trouble moving through his material
    Solution: help him along. Often people just need a leading question, but if somebody is too deeply involved with a subject, particularly a technical subject, it may be necessary to bring out the big guns -- "We've only got about X minutes left and I want to make sure we've got time for questions." If you don't feel comfortable saying this a few times in your career of operating a users' group, you're going to have a tough time
  • A speaker will cancel at the last minute.
    Solution: have a backup speaker ready to go at all times
  • Your backup speaker will be caught in such horrible traffic that he won't show up until the last ten minutes of your scheduled meeting
    Solution: have a presentation (or two) that you can give at a moment's notice
  • Your speaker gets lost, or forgets entirely about your meeting.
    Solution: The only solution here is proactivity. Make sure you get your speaker's cell phone number and call both the day before and the day of the meeting. Also, forward him both a link to the "directions" page on your group web site (you do have one, right?) as well as sending the directions in the body of an email. The email can be sent a week or so before the actual meeting so the speaker has a graceful chance to say "THIS month!? I'm in Bangalore this month!"

    Personal experience: A presenter from a Very Large Pacific Northwest Software Company once wandered around the group's previous meeting location while the rest of us waited disdainfully for him clear on the other side of town. A phone call or email beforehand would have solved this problem easily.

  • A speaker will flake completely and never show up or be heard from ever again.
    Solution: Same as above, but it's often a good idea to make sure you know somebody personally before counting on them to do a public speaking gig

Topics

There are as many topics that will be interesting to a good users' group as there are people who attend. Over the years, the Java users' group took on subjects as widely varied as Extreme Programming, VRML, and the local job market.

If you take on the responsibility of organizing a group, one of the perks is picking the occasional tangent topic that is of particularly interesting to you (so long as there's a connection back to your main subject area, of course!)

Keeping it Fun

For the Ruby crowd, it's less of a problem at the moment, but I can see ISPs and development software vendors offering to speak often enough that you could book late 2007 and 2008 with just sales pitches. Vendor presentations are often great, but it's good to mix it up with technical presentations.

I think workshops are a great idea right now -- a Rails install fest, for example. Hmm, that might only take the first ten minutes...

And, of course, Your Comments

I hope this post will live for quite a while, so please add any ideas you've found helpful in the comments section. If they remind me of specific advice, I'll revise the list above.

See you at the next group meeting!

2 comments | no trackbacks

Whoops! (Demoing Rails)

Posted by Gavin Doughtie Sat, 14 Jan 2006 21:30:00 GMT

I gave a Ruby on Rails demo recently at LAJUG, inaugurating their 10th year of operation since I started it in 1996.

I spent good many days writing a rudimentary outlining application to produce a PowerPoint-style slideshow.

Each day (and sometimes twice a day) I would execute “rails present” and proceed to rebuild my entire application from scratch so I could do a fluid presentation for the group.

I learned a few things about creating a good Rails demo, so here they are:

First, if you’re like me and the joy in programming is creating new functionality, be especially careful about feature creep. I probably blew an entire day fooling around with features I didn’t need to show. (Reording lists via AJAX calls comes to mind).

If you’re just trying to duplicate David Heinemeier Hansson’s excellent “Whoops!” screencast, then watch it as many times as you can stomach and make sure you can duplicate it screen for screen. There’s worse things you can do.

Practice, practice, practice!

Unlike more conceptual presentations, a good Ruby on Rails presentation, especially an intro presentation, should include running code. Running code means you need to rehearse, saying out loud what you intend to say as you do your demo, and looking for gaps in your presentation.

no comments | no trackbacks

Specialization, Money and Responsibility

Posted by Gavin Doughtie Sat, 17 Dec 2005 05:36:00 GMT

I’ll be 43 this Sunday. I write code every day. C++ Linux graphics code in the daytime, Ruby on Rails AJAX stuff at night.

Here’s what I think. Guys my age have mortgages and children. We need to earn at the higher end of our capacity. For some guys that means moving into management (for organizations that value management over engineering). For some it means developing ever more arcane specializations.

If you’re a twentysomething IT developer, you aren’t even going to see us specialized guys. We’re busy with problems that involve domain knowledge you’ve never needed to learn, fiddly weird hardware, languages that are too low-level, or too high-level to be part of mainstream curricula and entry-level jobs.

I ran a great number of developer interviews at one of the start-ups I worked at a few years ago. Almost all the candidates, young and old, were duds—but sometimes some graybeard engineer would show up and just floor us with his knowledge and understanding. Inevitably, he’d get a better offer, and vanish again into the rarified realms from which he descended.

I don’t think age is the issue. Value is. If you keep learning and remain valuable, there will be opportunity.

Posted in Software | 2 comments | no trackbacks

Where Ideas Come From

Posted by Gavin Doughtie Tue, 15 Nov 2005 04:04:00 GMT

Creativity is in the air.

Jill is writing her novel for NaNoWriMo, and Paul Graham is talking about new ideas for startups.

Me, I’m just trying to catch up after blowing off nearly all the boring, responsible stuff in my life to prep demos of xdraw for Web 2.0 and RubyConf.

At work, I’m derriere-deep in Purify and Valgrind, hunting down memory leaks.

Something I’ve noticed about creativity. It often needs to be preceded and followed by periods of “plain old work.”

Somewhere in the repetition, and boredom, and frustration of just working through something, you think “a #@!# computer could do this.” and POW!

That’s where they come from, for me, anyway.

Posted in Creativity | 1 comment | no trackbacks

Humans Should Not Be Machines

Posted by Gavin Doughtie Fri, 28 Oct 2005 21:32:00 GMT

I remember I met a mainframe programmer once who could compile IBM assembly code in his head.

Do you think he really misses doing that now?

People are creative, resourceful, pleasure-loving, inventive and funny.

So, why do we ennoble jobs that turn these wonderful creatures into interchangeable machines? Why do we fight to make assembly-line jobs high-paying?

We should be fighting to make it unprofitable to employ human beings in any endevour that is unpleasant, dangerous, demeaning or dull. Ancient Greek steam engines were never adopted because slaves were too cheap. Let’s go the other way, now that we live here in the future. Let’s push to make automation so cheap that even slaves are more expensive. (That way, you see, there’s no reason to have slaves).

Posted in Creativity, Software | 2 comments | no trackbacks

Yes And

Posted by Gavin Doughtie Thu, 13 Oct 2005 22:38:00 GMT

This morning on NPR I heard a piece about Chicago’s famed Second City improv comedy group teaching their techniques to Fortune 500 groups.

They mentioned the principle of “Yes, and” as opposed to “No, but.”

Macolm Gladwell talks about this in Blink. When improvising, if another player offers you a situation (“It seems as if your head is on fire.”) you must accept the situation and build on it (“Yes, can you put another log on it?” rather than “My head isn’t on fire, it’s your eyes that are burning.”)

I think the current entrepreneurial boom is a movement of “Yes, and” rather than, “No, but.”

Yes, we can make that happen. AND we can do it quickly and cheaply. AND we can build upon software that is freely available.

Funny how things can work out.

Posted in Creativity, Web 2.0 | 2 comments | no trackbacks

Better AJAX Chat

Posted by Gavin Doughtie Sat, 08 Oct 2005 20:39:00 GMT

So the demos I've been doing at Web 2.0 of xdraw, my shared vector-drawing application, have been using the fairly brain-dead "web page polls the server continuously for changes" approach to AJAX chat. Naturally, this is pretty bad for the health of my server (50% CPU consumption anyone?). The better approach is to have the server hold open the connection and jam data down the pipe whenever something changes. This is the system used by jotspot and the HTTP.push library. Stay tuned as I turn it on.

Posted in Web 2.0, Software, Ruby, AJAX, Javascript | no comments | no trackbacks

The Network Is The Client

Posted by Gavin Doughtie Fri, 07 Oct 2005 19:15:00 GMT

Just watched a demo from Mental Images, where a 3D visualization was rendered in real time on a server, and the resulting images streamed back to the web browser.

The images themselves were transmitted with lowres/hires pairs, so that when you stopped moving the mouse, you’d see a more bandwidth-intensive and pretty picture.

Now, this frees up the content owner to render from a scene that could possibly have gigabytes of data, while only sending small image files to the client.

But, really folks, it’s a nasty hack to make up for lack of client side 3D apis.

That got me to thinking, why don’t we have this? Ten years ago this summer, I remember sitting with the VRML dudes planning our new 3D future.

Didn’t happen. Here’s my theory:

At the time, the client was considered the “property” of client-side software companies. Thus, despite efforts at building consortia, the 3D plugins were developed and delivered as proprietary software which (partially) implemented a standard specification. Each software vendor wanted a proprietary advantage, and nobody opened their source. The business was never conceived of as something built atop an open, interoperable framework. It was culturally unsellable in a shrinkwrap software world.

It wasn’t just the wacky 3D browser world, it was more serious and potentially more useful technologies such as the now lowly Java applet.

Here’s what I think is coming. The business has moved from the browser to the server over the last decade, and all that money wants customers to have a great end-user experience. More importantly, a consistent end-user experience no matter what OS choice the user makes. So, we’ll fund Firefox and KHTML, sometimes with cash but more often with intellectual effort, to give us a better outlet for our businesses.

Posted in Web 2.0, Software | no comments | no trackbacks

A Brief Meme Summary

Posted by Gavin Doughtie Fri, 07 Oct 2005 03:12:00 GMT

I’m sitting here at the end of the second day of the Web 2.0 Conference. Here is a summary of the resident memes:

MONEY MONEY MONEY

Users own their own data

Data is the new proprietary advantage

MONEY MONEY

Google and Yahoo are the plug-in business model for many tiny web 2.0 startups

MONEY

Fools are poised to rush in, despite wise warnings to keep things small and not take funding.

Posted in Web 2.0 | no comments | no trackbacks

Older posts: 1 2 3