|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Monday, 6 March 2000||Author: Rick Moen|
|Published to: interact_articles_lugs/Articles||Page: 1/1 - [Printable]|
Recipe for a Successful LUG
Having seen (and run) quite a few Linux user groups (LUGs),and observed some thrive and others die, I can hazard somefirm 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.
|Page 1 of 1|
Last revised: 2000-02-17
The most recent version of this essay can be found at http://linuxmafia.com/~rick/essays/newlug.html.
Editor's Note: Definitely check the link above, this version is a bit stale. Thanks!
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 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 else, such as http://www.lugname.org.au/ . Consider choosing a group name whose Internet domain isn't taken (check at http://whois.networksolutions.com/cgi-bin/whois/whois, for USA domains), 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 such as Geocities -- but 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 meetings' location, instead, get discouraged, and maybe even conclude that your group has folded. 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, every time you move.
The location doesn't have to be good: 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, and PalmPilots -- 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 tech 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 dates: 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 knowledge initially, but must be "self-starters", and must have Internet access and know how to use it well.
8. You need to get on the main LUG lists, and keep your entries accurate.
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. For example:
Both of these lists are traps for the unwary LUG leader, in that they accept additions but appear to ignore correction/update notices: Once your entry becomes out of date, it stays that way.
9. 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  (or telnet, if necessary) to the 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.
10. 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.
11. Always include the day of the week, when you cite event dates. Always check that day of the week, first, using gcal  (or cal). gcal 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 matched the right day of the week to 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 the day wrong. That conveys the (probably accurate) impression that your calendar can't be trusted.
It doesn't hurt to print out the current year's "gcal" listings, for reference whenever you're doing calendar work. Mark significant holidays for your country on it: You can get them from http://www.holidayfestival.com/.
12. 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, and but also because it 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 out.
13. 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 MapQuest or 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 omits maps and directions, giving only the meeting date/time and the name of the building where it meets. 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.
14. 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.
15. You'll want to include an RSVP "mailto" hyperlink, on some events.
Set up an e-mail alias of "email@example.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., restaurants).
Other aliases you'll want -- if you operate your own Web server -- may include "webmaster", "postmaster", "president", "webteam", and "help".
16. 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 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:
17. 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) 2000 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 comments sharp-eyed readers who catch errors, omissions, and ambiguities in your public information 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 datestamp 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.
18. 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 former can and do move around or disappear without your having heard, and the latter can and will break because of your own imperfect maintenance.
There's a quick and easy way to catch all such breakage: Clear your Web browser's 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 broken links, if not other people's referral pages for sites 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 would be useful when, for example, your Web site moves or gets substantially reorganised, to advise the other webmasters. If you're feeling ambitious, try to find them. You will also find search engines useful for that task -- Google, Infoseek, Altavista, and others. (Don't forget deja.com, 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've had such a request on my Bay Area Linux Events page (http://linuxmafia.com/bale/) for five years, with zero responses.
19. 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.
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.
20. 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."
21. 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, and 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.
Addendum #1: A note about parent groups.
Many LUGs have 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, is technically a SIG (Special Interest Group) of the Silicon Valley Computer Society (SVCS, http://www.svlug.org/~svcs/).
The advantage to such an arrangement is that you can gain insurance coverage, 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 providing free Internet services for SVCS).
There are also offsetting disadvantages: Established PC user groups are often in decline, and 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, Linux-oriented companies, or other institutions friendly to Linux, 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 insurance and liability-protection, which shouldn't be a problem for modestly careful people.
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:
c. Periodically (maybe every quarter):
2. Other, periodical:
Addendum #3: Additional materials.
 ssh 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. Despite needing supporting software at both ends (server and client), it is rapidly replacing telnet, because the latter is horribly insecure and a leading means of account theft and system break-in. The best-known implementation is also named ssh. Client software is available for every consumer OS: See my list at http://linuxmafia.com/pub/linux/security/ssh-clients.
 gcal, the GNU calendar program, is a simple perpetual calendar utility included on typical Linux systems. Typing "gcal" shows the current month, while "gcal 2000" shows the twelve months of that year. On some systems, it will be named "cal".
Copyright (C) 2000 by Rick Moen, firstname.lastname@example.org.
|Page 1 of 1|