|
|
I am often invited to small and medium sized Free and Open Source Software events, and I enjoy going to them. Some of these events have been taking place for almost a decade, happening every year without interruption. Others happen only one or two times, then fade from view. Some suffer a stillbirth, and never make it to the first year.
|
|
Sometimes people ask my advice on their event, how to make it better, or even how to get it off the ground in the first place.
Often this advice is asked a few months before the time planned for the event, and that is often too late. Or people ask me how to recruit people to help them with the event after they have exhausted themselves by trying to put on the event single-handed.
The next couple of blog entries will be a “short course” to putting on an event. I do not guarantee that I will cover every aspect of it, but a lot of the "show stoppers" will be covered.
The first thing you should do is “build a team”. This will be a recurring theme throughout this set of blogs, because many hands makes for light work, many eyes see things left out of planning, and as you will find out, putting on an event can be more work than you ever believed. In addition, having multiple people join you early in the planning means that you will be less likely to have forgotten something, more likely to have better decisions made, and an all-around better event. Trust me on this.
The second thing you have to do is decide WHY you are going to put on the event. Most people would think of an obvious answer of “because there are no events in our area” or “because we would like to put on an event”, but both of these reasons will seem quite inadequate in the final few days of hectic work before the event actually happens. Involve your core team members in brainstorming on this task, which will both raise their excitement about the event and give them a feeling of ownership.
The WHY of the event is usually determined by questions such as
“What is the theme of the event?”
“Who is the target audience of the event?”
“How big should our event be?”
“What is your budget?”
A theme should reflect the general goal of the event. Are you trying to introduce people to FOSS, introduce a new part of FOSS code, attract business people to FOSS or build a community?
The audience might be “end users” or “systems administrators” or “programmers” or a combination of them. Each of these audiences might have subcategories such as “beginner”, “intermediate” and “advanced”, and (in the case of programmers) have different language interests (Perl, Python, Ada, etc.). Other audiences are “student”, “business”, “government”, “educational” and so forth. Your conference does not have to be limited to only one target audience, but you should know who those audiences are, since this will help not only in the planning, but how you contact them with advertising, and who your sponsors might be.
Size is measured not only in numbers of attendees, but also in number of simultaneous talks (called tracks), number of days that you run the event, whether you have a vendor area and other issues. It is highly recommended that you “start small” the first year, and build up over time. A one-day event with the right content can draw as many people as a multi-day event that is not executed well. The excitement generated by a smaller first-year event that is executed well will help you build the team and the momentum for a larger second-year event.
Your budget will be determined upon both your planned revenues and expenses. If you are planning on no entrance fee then you will have to get the bulk of your expense money (and you will have expenses) another way, perhaps sponsorships or donations.
After you have the anticipated size, you should look for a place to hold the conference, known as the “venue”. Finding a venue may be harder than you think, and the less time before the event, the harder it will be to find an appropriate (and affordable!) venue. Do not forget to investigate college and university venues. Many higher-learning institutions also have conference centers, and as an event that is promoting Free Software you may get a break on the cost of the venue.
Look out for “hidden issues” with the venue. Some universities will not allow vendors to display their wares. Many times hotels and convention centers will force you to buy all food (including coffee and donuts) from their “catering” service, which can be very expensive.
If your event is a family “community” event, then perhaps the best time is the weekend. If it is an “industry/business” event then you may decide to hold it during the week, particularly if it will be a larger event with real “booths” as opposed to “table-tops”. If vendors are going to send their employees to staff their booths at an industry event, the best days for the event may be Tuesday, Wednesday and Thursday so the booths can be set up on Monday, torn down Thursday night and the employees can still get home to spend the weekend with their families.
This is a good area for your team members to have input and to help you out. Determining the criteria for the venue, then making suggestions as to which venues to investigate, your team members can rapidly cut the number of venues to call and visit from their personal experiences, and reduce the strain on unique individuals further by having team members make the preliminary appraisals of the venue based on a set of criteria.
After you have selected the venue, you can look at the dates that you wish to have the event. Try and avoid major holidays (federal, state and local), university commencements and perhaps even major sporting events, since all of these affect hotel room availability and rates, as well as limit the times that the speakers can attend due to their family issues. Summer time is problematic due to family vacations, and as you can see, picking a date is not easy.
If your event is going to be drawing out-of-town attendees and/or speakers you will need some hotel rooms for them to stay. Depending on the size of the conference and the number of people expected, you will arrange for a “block” of rooms to be held by the hotel until a certain date before the event. After that the hotel will release the block and the attendees will have to hope that there will be rooms for them. Hopefully your attendees will register for the hotel rooms before the block of rooms is “released”. Make sure that your web pages give instructions about how the attendee should tell the hotel that the reservations is associated with the conference, so the room is taken from the block and not from the rest of the rooms in the hotel. Usually a discount code is given by the hotel for the attendee to use with the reservation.
If you are anticipating a lot of attendees, and they are of different “financial means”, you might have different classes of hotels and/or a “meetup” web page where people can “meet” to share rooms or find places to stay in local homes at low prices.
Now that you have a Theme, Date, Venue and set of rooms blocked you can start to make your announcements and invite your main speakers. You main "keynote" speakers should reflect your Theme, and your other speakers may either be invited, or answer a “Call For Speakers” where you outline the types of topics which you would like them to present.
Be aware that speakers of any notoriety have a busy schedule, and they may be booked nine months to a year in advance. They typically are “first come, first served”, and while you may be incredibly lucky and hit the ONE DAY that some great speaker still has open on their schedule, the later you wait to invite them, the more likely they are to be booked.
This is yet one more reason why starting your planning a year early is a good idea.
Next Blog: Ways of finding speakers. Full Story |
