The most recent version of this essay can be found at http://linuxmafia.com/faq/Linux_PR/newlug.html.

Recipe for a Successful Linux User Group

by Rick Moen

Last revised: 2016-02-25

Having seen (and run) quite a few Linux user groups (LUGs), and observed some thrive and others die, I can hazard some firm recommendations. If you're thinking of starting a LUG, or are running one now, please ponder these lessons, drawn from other LUGs' experience. In fact, please consider reviewing this list from time to time, as a kind of checklist.

1. You need a Web page.

I can't stress this enough. The Internet is crucial to Linux: It made Linux possible, and is where everything happens. If your group isn't on the Net, it might as well not exist.

By "the Net", I mean not just Web pages, which are its most-visible service, but also mailing lists, Usenet newsgroups, and Web/ftp file archives, among other things. It's your source for software, the forge where open-source tools are designed and crafted, your method of publication, your social club, and your research library.

Each major function of your group should have a Web page: If you start doing InstallFests, create an InstallFest page.

2. Your Web page needs a reasonable URL.

The usual http://www.some-isp.com/~username/lugname/ URL isn't good enough: You want people who know no more than the group's name to find you easily. For that, http://www.lugname.org/ is ideal in the USA — and you can use similar formulas elsewhere, such as http://www.lugname.org.au/ . Consider choosing a group name whose Internet domain isn't taken (check at internic.net, or other WHOIS facilities) and then paying to register that domain and have an ISP virtual-host it. It's not that expensive.

Given that this is the Linux world, the odds are that one or more of your core volunteers owns a co-located Internet host, and will be willing to host your pages and domain for free.

The odds are that your Web page will start out somewhere less desirable, such as a subdirectory of someone's home page, or a free hosting service — but you should aim towards having your own domain, in the longer term.

Remember that the Net is world-wide: If the best/cheapest hosting is at (say) a friendly LUG site on another continent, take it.

3. You need a regular meeting location.

Changing meeting locations risks losing attendees like mad. Why? Because some will come to the prior meeting location, instead, get discouraged, and maybe even conclude that your group has folded — and also because finding out how to get there, where to park, whether the neighbourhood's OK to walk in, etc., is a strain on people, each time you move.

The location doesn't have to be impressive: I've seen a college cafeteria suffice for one group, and a small downstairs room in someone's house do well for another. It just has to be reliably usable.

4. You need a regular meeting time.

"Regular" usually means following an easily-remembered-and-used formula, suitable for people's calendars, pocket planners, PDAs, smartphone reminder apps, etc. — such as 4th Thursday. Don't get fancy with things like "every other Thursday": Make it so anyone with a calendar can easily figure out when the next meeting will be.

5. You need to avoid meeting-time conflicts.

Check out the schedules for nearby technical events: Linux user groups, Perl groups, and whatever else your target audience is likely to want to also attend. Don't pick recurring dates that those other groups are already using. Hint: 1st & 2nd Tuesdays, Wednesdays, and Thursdays are over-popular meeting days: Their attraction is that they're easy to remember — and mid-week days are generally good for people. But, in my immediate vicinity (for example), there are four competing groups sharing first Tuesdays.

6. You need to make sure that meetings happen as advertised, without fail.

One LUG in my area fell apart largely because the president set an aggressive meeting schedule, and then failed to show up to unlock the meeting room. Would-be attendees then looked up the next meeting date on the Web, showed up, found a locked door, and (soon) give up on the group entirely. So, if possible, have multiple people arrange to show up early. Also, post signs/flyers near the meeting site.

If you need to cancel or reschedule an event that you've already been advertising as "upcoming", don't simply remove the original listing on your Web pages: Continue to list it, prominently marked as cancelled/rescheduled.

7. You need a core of several Linux enthusiasts.

LUGs have succeeded wonderfully on the strength of ongoing efforts from as few as four energetic and inquisitive people. That's really all you need, but one or two are not enough. E-mail is terrific for coordination.

Your core enthusiasts don't need any Linux knowledge initially, but must be "self-starters", and must have Internet access and know how to use it well.

8. Your core volunteers need out-of-band methods of communication.

By that, I mean outside your user group's regular electronic means of communication. One college LUG operated all e-mail mailboxes used by its officers through the LUG's Web server machine, which then went down at the beginning of summer recess. It thus proved the proverbial "single point of failure" for group communications. Most officers change residences at the academic year's end, and there weren't even summer LUG meetings scheduled for regular dates, so the LUG nearly collapsed because its principals lacked any means of getting back in contact with one another.

Having circulated a list of stable non-LUG e-mail addresses, telephone numbers, and/or postal addresses would have averted this near-disaster.

9. You need to get on the main lists of LUGs, and keep your entries accurate.

There used to be many more LUG lists covering the whole world, but all of the global-scope lists other than the DMOZ one have quietly folded. (Thankfully, the excellent Lugslist and Léa-Linux lists recently arose to take their place.) Some of these abandonments have been surprising and disappointing, such as the sudden erasure of linux.com's (deleted without notice around September 2002 when owner VA Software Corporation blew away all Web pages not aimed solely at the Fortune 500: oh well, no big loss), SSC's GLUE = Groups of Linux Users Everywhere list, and Red Hat, Inc.'s LUG Resources pages. Also, linux.org / LinuxOnline and linuxhq.com's lists evaporated with the partial collapse of Michael McLagen sites, and LUGs WorldWide Project's pages folded.

The GLUE list was a particularly grievous loss: SSC, Inc., which back in 2005 was best known as the publisher of Linux Journal, in that year summarily deleted the GLUE directory and replaced it with a Web redirect to www.linuxjournal.com. That extensive LUG database and information exchange is sorely missed, and it's a shame SSC offered nobody in the Linux community any opportunity to adopt the GLUE site. (SSC itself also folded, a few years later.)

Assign someone in your group to re-check your LUG list entries periodically, say, every quarter. You'll be amazed at how inaccurate they become over time. Keep a list of all the places where you have such entries, and also a "publicity" list (of places you send notices of upcoming events). Sometimes, it helps to print these out and use them literally as checklists.

An inaccurate LUG-list entry is often much worse than none at all: When it directs prospective members to an obsolete URL, or tells them the wrong meeting date, that actively hurts your membership effort.

So, before submitting an entry to any LUG list, do some spot checks on the existing entries' general level of accuracy. Widespread inaccuracy (e.g., dead links, wrong information on meeting dates and places) may indicate a hidden gotcha: Some lists are so badly maintained that their staffers ignore corrections you send in.

Such a list is a trap for the unwary LUG leader, in accepting additions but appearing to ignore correction/update notices: Once your entry becomes out of date, it stays that way. (This essay's longtime example of such a list vanished when the LUG-list site in question, that of the late Computer Currents magazine, vanished.)

10. You must have login access to maintain your Web pages, as needed.

An unchanging page that someone else created for you isn't good enough: You need to be able to fix/edit/enlarge your site on short notice. Typically, this requires login access via ssh[1] to the hosting Web server's command shell.

A number of Linux groups attempt to get by with a static page on some site to which they themselves lack maintenance access — for example, on a parent group's existing Web site. The convenience isn't worth the disadvantages: Don't go that route.

11. Design your Web page to be forgiving of deferred maintenance.

Much as we'd like our LUGs' "upcoming events" and other time-sensitive information to be always current, it isn't going to happen: Sometimes, you don't re-check and update them for a week or two. Therefore, always list several months' upcoming events. (You know when they'll be because you have a meeting-date formula, right?) That way, when you're unavailable for Web-page maintenance for two months running, the Web page will still include current meeting information.

Somehow, my local LUGs' webmasters seem resistant to that simple idea, with the result that most list only one upcoming meeting at a time, which, for three quarters of the month, because of the inevitable deferred maintenance, ends up being last month's date.

The whole point of listing specific upcoming meeting dates is to make it unnecessary for casual visitors to work out when the next (say) 2nd Tuesday will be, by doing it for them. But that effort is wasted when the only meetings shown are already past: It makes new LUG members that much less likely, and additionally may lead some to think your LUG is now defunct.

12. Always include the day of the week, when you cite event dates. Always check that day of the week, first, using cal[2]. cal is your friend.

Why always include the day of the week, on event listings? Because that gives viewers their best shot at remembering your event, how many days away it is, and how it fits into their schedules.

Additionally, the fact that you've furnished the correct day of the week for each date reassures visitors that you haven't messed up and listed the wrong date (which happens depressingly often) — in effect, a cross-check. Conversely, take care not to list a meeting's date correctly, but with the day wrong. That conveys the (probably accurate) impression that your event calendar can't be trusted.

It doesn't hurt to print out the current year's "cal" listings, for reference whenever you're doing calendar work. Mark significant holidays for your country on it: You can get them from religioustolerance.org, web-holidays.com, Mozilla Holiday Calendars, Apple iCal Calendars, etc.

As the old joke goes, "Dates In Calendar Are Closer Than They Appear." Use whatever works to ensure that announcements of upcoming events go out on time, which for most groups means somewhere between 1 week and 24 hours before show time. Personally, I find this simple script tool handy as utility /usr/local/bin/daysutil, to do quick checks from the shell prompt:

#!/bin/sh
echo "Type the future date in ISO 8601 (YYYY-MM-DD) format."
#Functions mktime & systime, used below, require the GNU awk interpreter
read futuredate
echo $futuredate | tr -s '-' ' ' | awk '{dt=mktime($0 " 00-00-00")-systime(); print int(dt/86400+1) " days";}'

13. Place time-sensitive and key information prominently near the top of your main Web page.

Don't banish all meeting information to your events page, or tuck it into an unobtrusive text box for aesthetic reasons: Ensure that the most prominent items on your site are the ones viewers need most. Consider using "STRONG" or "EM" HTML tags on particularly important items, such as your date formula (e.g., "second Tuesdays at 7 PM").

Displaying time-sensitive information prominently is useful not only because that tends to be what viewers seek most often, but also because such text calls your attention to itself, when it needs updating. Think of this as comparable to putting perishables near the front of your refrigerator, date-stamp outwards.

14. Include maps and directions to your events.

Some prospective members will be comfortable with maps, others with directions; you'll want to help both. Maps can be generated (for the USA, at least) on OpenStreetMap, Google Maps, MapQuest, or Bing Maps (formerly MSN Maps, formerly MapBlast). Have them as links for each listed event location. If there's a trick to parking nearby, describe it. If public transit is available, give details.

Remember: Directions and maps are (particularly) for people who aren't yet members, not for your existing "in-crowd". The Web page for one LUG near me used to omit maps and directions, giving only the meeting date/time and the name of the building where it met. Don't fall into this common trap of making your pages useful only for existing LUG members.

One of the themes of this essay, in fact, is: Try at intervals to look over your LUG's public information as if you were an interested newcomer. Does your public information (e.g., your Web pages) tell prospective members what they need to know? Is the most important and most time-sensitive information also the most prominent? If not, you need to redesign it.

15. Emphasise on your main page that your meeting will be free of charge and open to the public (if it is).

Believe it or not, some prospective members will assume your group costs money, unless you say otherwise. This is especially true of people accustomed to traditional user groups, which generally must charge dues to finance their dead-tree-media newsletters and other money-intensive operations. (See addendum #1.)

Conversely, if there will be an attendance fee (e.g., to pay for dinner), say so prominently, with the other event details.

16. You'll want to include an RSVP "mailto" hyperlink, on some events.

Set up an e-mail alias of "rsvp@groupname.com" pointing to the real mailbox of one or more volunteer, and include it as a link on event listings when you need an advance head-count (e.g., at restaurants).

Other aliases you'll want — if you operate your own Web server — may include "webmaster", "postmaster", "president", "webteam", and "help". If you use such aliases consistently for roles people fill, you'll be better equipped to handle smoothly the inevitable turnover in volunteers, over time.

17. Use referral pages.

Over time, you'll find it desirable to reorganise your Web documents, rename pages or directories, or move the whole site (or part of it) to a different Web server. That's inevitable — but don't forget that other Linux groups, user group lists, search engines, and assorted individuals will have already created links to your old URLs, without telling you they've done so. Thus, if you just move/rename your Web documents, you will break one means by which interested parties are accustomed to finding you.

The cure is to leave a "referral page" at the URL where the document used to be, guiding the user to its new location. Get in the habit of doing this whenever you would otherwise leave nothing where there used to be a page: It's better than their getting a 404 error.

Here's an example:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="refresh" CONTENT="2; URL=http://www.newlocation.com/">
<TITLE>New location for FOO Home Page</TITLE>
<HEAD>
<BODY>
<H1>The FOO home page has moved!</H1> The new location is <A HREF="http://www.newlocation.com/">http://www.newlocation.com/</A>
</BODY>
</HTML>

2008-11-13 note: A correspondent wants me to replace the above with a recommendation of doing httpd status code 301 (permanently moved page) redirects inside the Web server configuration file. This is indeed ideal — for those who have access to reconfigure and then restart the relevant Web server, and who also have mastered configuration of that particular software. (Naturally, "permanent redirect" details differ between Web server packages.) The problem with the above-described META refresh technique is that spammers' pages use it to try to trick search engines, and so the engines discount the "page rank" (etc.) value of such links.

Other aspects of site configuration can complicate implementation of a 301 redirect, such as whether the httpd maps multiple domains to the same IP. Anyway, if interested in this sort of webmaster neepery, you know how to search for it. (If tempted to use Apache httpd's "mod_rewrite" code as opposed to "Redirect permanent" or "Redirect 301" directives for such a project, best of luck to you.)

18. Make sure every page has a revision date and maintainer link.

It's traditional to put some variation on "Send feedback to [link]" or "Copyright (C) 2016 by [link]", or "Webmaster: [link]" where "[link]" is the maintainer's name with a "mailto" hyperlink. And there's a good reason for this tradition: It ensures that "feedback" comments — from sharp-eyed readers who catch errors, omissions, and ambiguities in your public information — will reach the right person. Make it easy for the public to help you, and some of them will.

Putting a date stamp at the bottom of each page, whenever you update it, reassures visitors that the site really is current. You may know that it's a living site with current data, but newcomers won't. Dead sites with obsolete data are far too common on the Web, and the date stamp marks your page as freshly edited. (Equally, it reminds you of when you last overhauled the site.)

Need I mention that the worst-maintained LUG sites in my area lack revision dates and maintainer links? It's true.

19. Check all links, at intervals.

Probably your pages will contain numerous links to external sites, as well as to other parts of the same site. The remote sites can and do move around (or disappear) without your having heard, and local links can and will break because of your own imperfect maintenance.

There's a quick and easy way to catch all such breakage: Open your Web browser and clear its cache, which makes all links appear as unread. Now, visit each link in turn. If you do this at intervals (e.g., every six months), you'll at least find any broken links, and maybe other people's referral pages for remote pages that have moved.

It's possible (but a non-trivial task) to find all sites that link to your pages, by analysing your Web server's log files. That knowledge will prove useful when, for example, your Web site moves or gets substantially reorganised. (You can then advise the other webmasters.) If you're feeling ambitious, try to find them. Search engines are useful for that task: DuckDuckGo, Google Search, and others. (Don't forget Google Groups Search, formerly DejaNews, for searching Usenet posts.)

One tactic that doesn't work: putting a note to webmasters on your site, asking them to let you know of links to it. I had such a request on my Bay Area Linux Events page for more than ten years, with zero responses (now so many more years than that, I've lost count).

20. You may want to consider establishing a LUG mailing list.

Any reasonable Linux host (machine) with a constant Internet connection can run mailing-list software. GNU Mailman (http://www.list.org/), for example, is easy to set up and administer, and comes with automatic Web-archiving for your mailing list. Many groups find it useful to have both a main discussion list and a low-volume announcement-only list. (As a warning, the difficult part is doing effective antispam in the mailer daemon software.)

Do not announce your upcoming meetings only to your mailing lists: By definition, those will reach only existing members. The whole point of having a public presence (e.g., Web pages) is to both serve existing members and attract new ones.

Some commercial services let you set up "free" mailing lists on their servers, where their gain lies in revenues from mandatory ads auto-appended to all posts, plus of course the ability to sell your subscription list to other advertisers. Beware that you may find yourself not the "owner" of your own list, in the event of a dispute over its management.

Some groups have founded Web-based discussion forums, instead of e-mail mailing lists, either on their own servers or on commercial services. I have yet to see one that wasn't stagnant and inbred. The advantage of e-mail mailing lists is that e-mail is universal and convenient for people, generally.

If you do run LUG mailing lists, someone will have to function as list "owner", taking care of administrative requests and enforcing list policy. The latter category will include dealing with job recruiters: Many LUG lists have been overwhelmed with job ads from professional recruiters, sometimes posted multiple times a day. A policy that has worked well at one LUG is to require that all job ads be submitted to a club officer, who then posts it with a subject header starting with the string "JOBOFFER:" That way, the jobs postings' volume can be controlled, and people not wanting to see them can filter on subject headers.

21. You don't need to be in the Internet Service Provider business.

Leave the ISP business to the professionals. You won't be able to beat their prices, so don't try. When the moochers in your crowd ask for dial-in lines and shell accounts on the group's Web server, say "No."

22. Don't go into any other business, either.

I hear of LUGs being suckered into the strangest, most cockamamie business schemes. Don't: Don't try to be a Web design firm, a technical support firm, a network design consulting firm, or a LAN cabling contractor. Or any other business. Not even if you're told it's for a wonderful charitable cause.

Along the same lines, remember that you are not a convenience for job recruiters: If allowed, they will spam your mailing lists and abuse every possible means of communication with your members. Nor are you a source of computers for the underprivileged, a repair service for random people's broken PCs, or a help desk for non-Linux operating systems and applications. Believe it or not, you will be pestered by all of the above sorts of strangers, on the "nothing ventured, nothing gained" theory.

23. Walk the walk.

It's painfully grotesque to see so-called Linux user groups mailing out announcements using MS-Outlook or Eudora for MS-Windows (or MacOS), or other proprietary mailers for legacy operating systems — and visibly maintaining their Web sites using MS Front Page, Adobe Page Mill, or other junkware — and hosting their LUG mailing lists on Yahoo Groups (formerly eGroups and Onelist, formerly MakeList) or Google Groups. Fortunately, these LUGs are in the minority, but they convey the message of Linux being suitable in neither desktop nor server roles.

If you are going to promote and explore Linux, you need to use it. If you don't know what good, open-source tools for Linux exist to create and manage Web sites (such as Bluefish, Screem, Mozilla Composer, Amaya, and Quanta Plus), then ask around. Ditto for mail user agents: Ask around, and you'll hear about excellent native-Linux mailers such as Mutt, Mozilla Thunderbird, Sylpheed, KMail, Mahogany, Balsa, Aethera, Evolution, Pronto, and Spruce. Ditto for mailing list hosting: It's just unbelievably feeble and lame to have Yahoo Groups, Google Groups, Topica, or some other "free" commercial service run your mailing list when GNU Mailman comes already set up and working on major Linux distributions, complete with automatic Web archiving and Web-based administration — plus you can even add to it mnoGoSearch as an archive search engine, if you wish.

2016 addendum: An even worse trend has been turning user groups into Meetup.com groups, about which ignominious failure I have a separate Meetup rant.

Don't volunteer to look like losers in public: As the saying goes, a LUG needs to "eat its own dog food".






Addendum #1: A note about parent groups.

Many a LUG has gotten started as a sub-group of a more-established parent, usually a general-purpose computer user group. For example, SVLUG (http://www.svlug.org/), one of the world's largest LUGs, when founded and for many years thereafter, was technically a SIG (Special Interest Group) of the Silicon Valley Computer Society (SVCS).

The advantage to such an arrangement is that you may be able to gain incorporation and acknowledged non-profit tax status, without having to handle the paperwork and expense of those efforts, yourself. Depending on the people involved, the relationship can also create genuine symbiosis (such as SVLUG having provided free Internet services for SVCS).

There are also offsetting disadvantages: Established PC user groups are often in decline, and tend to be run by people devoted to legacy proprietary OSes who have no understanding of Linux or open-source software. The potential for culture clash is a serious one, and the odds are that your LUG members will have little interest in the parent group's other functions.

Old-line PC user groups tend to have annual dues of US $40 and up, for all members, and often charge admission for their monthly meetings. They adopt this model in order to finance their paper-published newsletters, (sometimes) to rent meeting space, and to pay sundry administrative costs such as telephone and corporate-filings fees.

By contrast, a LUG can operate with expenses approaching zero: Its publications can be Web-based. Notices can be sent via e-mail instead of on flyers. Meeting space can usually be gotten for free at ISPs, colleges, pizza parlours, brewpubs, coffeehouses, computer-training firms, Linux-oriented companies, or other friendly institutions, and can therefore be free of charge to the public. Having thus arranged to have roughly zero revenues as well as expenses, there is little need for tax-exempt status or incorporation. About the only thing you forego without incorporation is a corporation's legal liability shield.

The corporate liability shield is often badly understood: It merely limits a business's potential losses to the equity stake of the owners. In no way does it immunise corporate officials for the results of actions they're involved in doing, for example. In any event, liability shouldn't be a problem for modestly careful people, anyway.

So, the advantages of having a parent group are somewhat smaller than would appear at first glance. You may find the parent group trying to dictate your sub-group's policies, including the content and location of its Web pages, and unhappy with your members who disregard the parent group and fail to pay its membership dues. This has led some Linux SIGs to split off from their parents as independent LUGs. Others quickly become the tail that wags the dog, as with SVLUG and SVCS. Some groups achieve other long-term arrangements, with varying degrees of happiness on both sides.

Be aware of the issues and possible outcomes, in any event.






Addendum #2: LUG checklist.

The following checklist may be useful for your group, once established.

1. Web page:

a. Meetings:
[ ] Current meeting info? Is it prominent?
[ ] Day of the week? Beginning time? Ending time?
[ ] Double-checked day/date matches against a calendar?
(E.g., is the "Friday, March 28" you listed an error, because the 28th is a Thursday?)
[ ] Location?
[ ] Map?
[ ] Directions (car, public transit)? Parking tips?
[ ] Information on the next several meetings?
[ ] RSVP mailto link on meetings where this is needed?
[ ] Note that meetings are free and open to the public (if they are)?
[ ] If there's a special fee, is it disclosed next to the event listing?
[ ] If location / time / date formula has changed recently, is this noted prominently?
[ ] Have you checked for event conflicts with other nearby groups, or with holidays?

b. General:
[ ] Includes event date-formulas (e.g., 4th Tuesdays)? Prominently?
[ ] Maintainer mailto link?
[ ] Last-revised date?

c. Periodically (maybe every quarter):
[ ] Checked all links on your site for dead links?
[ ] Checked your Web server's logs for pages requested but not found? (You'll want to put a referral page at that URL.)
[ ] Read all your Web content attentively for outdated content?

2. Other, periodical:
[ ] Reviewed/updated all LUG lists that have entries concerning your group?
[ ] Reviewed all sites that link to yours? Advised their webmasters of needed corrections?






Addendum #3: Additional materials.







[1] ssh (secure shell) is a protocol for encrypted remote login (and inter-system file transfer), protecting both your login authentication and the subsequent session data against third-party eavesdropping. Starting in the 1990s, it comprehensively replaced telnet because the latter was/is horribly insecure and was then a leading means of account theft and system break-in. ssh implementations are available for all OSes in common use.

[2] cal, the GNU calendar program (sometimes called gcal), is a simple perpetual calendar utility included on typical Linux systems. Typing "cal" shows the current month, while "cal 2000" shows the twelve months of that year.

Copyright (C) 2000-2016 by Rick Moen, rick@linuxmafia.com.
Verbatim copying, distribution, and display of this entire article are permitted in any medium, provided this notice is preserved. Alternatively, you may create derivative works of any sort for any purpose, provided your versions contain no attribution to me, and that you assert your own authorship (and not mine) in every practical medium.