How to Start a Local Linux User Group Meetup

Every town has Linux users. Most of them are alone with a terminal, one man page away from an answer that someone three streets over could give them in four minutes. A local user group closes that gap. Starting one takes less than most people expect: a room you can return to, a repeating date, and one friend who shows up even when nobody else does.

Find a room you can return to

Groups rarely die of boredom. They die of venue churn. Before you announce anything, find one place that will host you on the same weeknight every month, and confirm the details properly rather than trading vague messages.

Libraries and community centres are the usual starting point, and plenty of them have meeting rooms sitting empty on weekday evenings. Hackerspaces, co-working spaces, university labs, pub back rooms and the occasional generous employer with a spare conference room all work too. A library is often the easiest first ask, because the staff already know how to handle a public booking.

What to ask before you commit

• Can we book the same evening every month, or do we book session by session?
• Is there a charge, and does it change once we become a regular booking?
• What time does the building close, and does that include time to pack up?
• Is there a screen or projector, and which cable does it take?
• Is guest wifi available, and how do visitors get the password?
• Is the entrance step-free, and is there an accessible toilet?

Write the answers down. You will be asked all of them again, every month, by someone standing outside a locked door.

Pick a format that survives the second meeting

A single presenter carrying the whole group gets tired by month four. Choose a format that spreads the work and still functions when the scheduled speaker cancels on the day.

Formats that hold up over years:

• Lightning talks. Five talks of five to ten minutes each. Low preparation, high variety, and a natural way to get first-timers on their feet.
• Fix-it night. Everyone brings a broken machine, a failing backup, or a server they cannot reach. Work in pairs.
• Show and tell. Home labs, dotfiles, terminal setups, self-hosted services, whatever someone built this month.
• Study group. Work through a certification syllabus, a kernel topic, or a book chapter together, one chunk per meeting.
• Install fest. Blank laptops, live USBs, and a lot of patience. Bring spare drives and a wired connection if you can.

A default agenda keeps the evening moving:

1. Arrivals and informal chat for the first fifteen minutes.
2. Short announcements: jobs, events, hardware anyone is giving away.
3. Main talk or demo, thirty to forty minutes.
4. Questions, which usually turn into the real discussion.
5. Social time until the venue closes or people drift off.

None of this has to be polished. A ten-minute demo of a shell trick, a walkthrough of a RAID array someone rescued, or a tour of a home server is a perfectly good meeting.

Make the first meeting small on purpose

Do not book a lecture theatre for your debut. Six to twelve people in a normal room feels like a group; the same six people in a hall feels like a failure. Pick a room that looks slightly too full and you will spend the evening apologising for the chairs instead of talking about anything interesting.

Open with introductions and three questions: what are you running, what do you use it for, and what is currently broken or confusing? That third question is the most valuable thing anyone says all evening. Write the answers down. You have just been handed a programme for the next six months.

Bring a spare laptop, a live USB, and a power strip. Someone always arrives with a machine that will not boot, and fixing it in front of everyone beats any slide deck.

Get the word out, in one place

Scattering details across five platforms guarantees confusion about which room you are in. Pick one page that holds the date, time, address, room number and a way to ask questions. Everything else points at that page.

Then post where local people actually look: a regional tech chat, a university computer society board, a library noticeboard, a local subreddit, a Mastodon or Fediverse account with a location in the profile, and the mailing lists of any existing groups within an hour's drive. A short printed notice near a campus coffee shop still works better than most people assume.

Announce twice: about two weeks before and again the day before. Expect a portion of RSVPs not to appear — that is normal and not a verdict on your organising. Say explicitly that the meeting happens regardless of how many people reply, so a first-timer never turns up to an empty room.

Deal with the boring logistics early

Most complaints about a meetup are not about the content. They are about the room.

• Carry a USB-C to HDMI adapter and a VGA one if the venue is older than you think.
• Put a printed sign at the entrance with the room name. Venues move bookings without telling anyone.
• Post travel notes: nearest station, bus route, parking, and which door is unlocked after hours.
• Bring a power strip and a short extension lead. Laptop batteries lie.
• Publish a short code of conduct, and keep it plain: be decent, no harassment, ask before photographing.

Keep money out of it if you can. Free rooms and no catering remove an entire category of administrative work. If you ever do collect money for a venue or snacks, keep a simple record of what came in and what went out, and take proper advice on any tax or legal obligations that apply where you live.

Keep it alive past the first year

Share the load. One organiser burns out; two or three people with access to the same calendar, inbox and notes do not. Rotate who runs the evening, and let people give talks on topics they are still learning — a talk about something you just figured out is usually better than one about something you mastered in 2012.

Schedule the next date before anyone leaves the room. A group with a fixed slot, say the second Wednesday of every month, survives far better than one that negotiates each time.

Allow a no-talk month. Call it a hack night: bring a laptop, work on your own project, ask whoever is next to you when you get stuck. Those evenings often produce the best conversations of the year.

And keep the door open to beginners. "I use Ubuntu and I am stuck" is a complete and welcome introduction. Debating what counts as real Linux is a fine joke and a terrible membership policy.

The measure of a good user group is not attendance figures. It is whether two people who met there are still trading answers a year later.

Put a date on the calendar this week

Email one library, book one room, and set one recurring date. Write three sentences describing the meeting and post them in one place. Invite the two people most likely to come. That is the whole job for month one.

Then show up early, put the sign on the door, and wait. Someone will walk in with a laptop bag and a problem, and the group has started.

Photo: Diva Plavalaguna / Pexels