On bootstrapping a community-run FOSS event

On Saturday, April 10th, I was in Austin Texas for the inaugural Texas Linux Fest (TXLF), a community-run FLOSS conference. The idea to stage the show arose last August during OSCON, picked up steam in the fall, and in the end a little under 400 people turned out — including speakers and volunteers — which most considered a successful number for a first year event.

The fact that it worked demonstrates that the developer and end-user open source community is eager to get together. But that fact guarantees no automatic success; along the way the TXLF planning team met challenges that anyone investigating launching their own regional show could learn from — as well as opportunities where the open source community could build tools useful for a wide range of all-volunteer projects.

Brief background

The genesis for TXLF was a series of independent conversations along the lines "there should be a regional community Linux show in Austin," mostly by Matt Ray of Zenoss and myself, with other people. Eventually both Ray and I had that conversation with Ilan Rabinovitch of SCALE, who told us to start talking to each other. Gathering all of the interested parties in one place was the first challenge. There is little you can do other than put the word out in every conceivable medium and see what happens — the group contacted individual free software hackers, business contacts, and every regional LUG and developers' group with an active presence on the Internet.

As the collection of interested parties expanded, counting out the tasks involved in putting such an event together became the next hurdle. Many of the team had personal experience at least participating in some aspect of behind-the-scenes conference work — as an exhibitor, a speaker, or a volunteer — but as no one had the freedom to work full-time on the task list, organizing it became an ad-hoc affair. I eventually took on the role of trying to keep the geographically dispersed team coordinated on the to-do list, and worked on raising sponsorships, marketing, working with exhibitors, and helping to develop the program.

Inertia and chicken-* problems

At the practical level, the biggest obstacle a community-run event faces is inertia. There are at least three types. First, all of the volunteers are likely to be enthusiastic about the idea of the event, but individuals generally cannot devote their time to working on it until they personally cross the "I'm sure it's going to happen" threshold. For some it is lower than for others — particularly those with behind-the-scenes conference experience. The challenge is for the team to move forward in the early stages and thus grow the pool of volunteers that can make time to pitch in. For each individual, though, the inertia is not lack of interest in helping out on the project, it is simply human nature to put tasks on the back burner until the project becomes real enough to move up in priority.

The second type of inertia is just a lack of group structure. In the case of TXLF, very few of the volunteers knew each other well, none had worked together before, and as a result it was at times difficult to come to a consensus on nuts-and-bolts decisions such as "should there be a free ticket option, or should all tickets be priced," or, "who should we invite as a keynote speaker?" In most cases, there is no right or wrong answer and often no strong opinions, so in a democratic group the best option is often to simply vote and make do with the results.

The third type of inertia, though, is the biggest challenge: the seemingly intractable problem of having three or four mission-critical decisions, all of which must be made first. In the case of TXLF, it was the date, the venue, and the sponsors, a chicken-and-egg-and-rooster problem, if you will. Selecting the date first risks eliminating availability of key sponsors or venues; selecting the venue first limits the choice of dates and means gambling on the ability to raise enough sponsorship to rent the venue; gathering sponsors first is impossible because without a date and a venue, they do not know their availability and may doubt whether or not the event will genuinely come to pass. Other events or volunteer projects may face a different combination; in any case there is no simple answer. TXLF selected the date first, attempting to minimize interference with other FOSS and local events — even so, the date selected ended up conflicting with COSSFEST.

Knowledge capture

Once in the planning process, however, the challenges become all practical. Arguably the biggest impediment to planning a new event is that there is no definitive guide to the process. There is a generally-accepted list of the "large scale" components — asking sponsors for support, putting out a call-for-participation, opening for registration, arranging for audio/video at the venue, setting up the network, publicizing the event, etc. — but nothing in the way of a step-by-step guide that can break the tasks down for easier group consumption.

Fortunately, most of the existing regional open source conferences do much of their own planning in public (from mailing lists to wikis), which makes for good reference material at the early stages. Even better, all of the organizers are dyed-in-the-wool enthusiasts who will offer their assistance to answer questions, refer questions to others, and in many cases actually pitch in. TXLF received a tremendous amount of help from the SCALE organizers (some of whom even volunteered in-person), as well as from the teams behind LinuxFest Northwest, the Florida Linux Show, Southeast LinuxFest, and Ohio LinuxFest.

Speaking to someone who has organized an event before gives a new team more specific insight into the process of dealing with the contractors and volunteers to make arrangements. For example, knowing that certain companies will not agree to sponsor an event until there is a public call-for-participation, learning how to negotiate counting concession sales against venue rental price, or what sort of wording needs to go into the exhibitor agreement for an expo booth.

The TXLF group came by most of this knowledge through person-to-person conversation and mailing list or IRC discussion. A considerably better approach for the future is the FOSSEvents.org site, which SCALE's Gareth Greenaway discussed in a session at TXLF. FOSSEvents.org is a newly launched site sponsored by the Peer-Directed Projects Center (best known for Freenode) that hopes to serve as a focal point for community-run free and open source software events, whether conferences, hackfests, or informal meet-ups.

The plans include several services, such as a central location where speakers willing to present at FOSS events can register their availability and contact information, but one of its high-priority tasks is building a wiki-style guide to the event planning process. FOSSEvents.org already provides a searchable calendar of such events, which is itself a valuable resource. A number of people in the audience for Greenaway's presentation raised their hands when asked if they were planning an event of their own, so the service is certainly needed.

At present, the TXLF organizers and all on-site volunteers are attempting to collect and process their own observations and feedback on the event, both for institutional knowledge and to better share with other groups like FOSSEvents.org. The challenge, as always, includes time, but also stems from the organization software tools themselves.

Tools, and the lack thereof

One of the biggest surprises of coordinating the first-year event was seeing firsthand where free and non-free software fit the bill. In some areas, there was no surprise — the networking team built the wired and wireless network at the venue with open source, as one would expect. All of the design and pre-press work for the fliers, ads, shirts, and program guide was done with Inkscape, Gimp, and especially Scribus, which evidently surprises some who are not as familiar with those applications. There are even a few open source conference-management packages to handle tasks like registration, call-for-participation, and scheduling. ConMan from the Utah Open Source Conference is one such package that is still being developed; TXLF used SCALE's SCALEreg specifically for its registration, on-site check-in, and badge-printing capabilities.

On the other hand, at multiple points the group found itself using closed-source solutions — particularly for collaboration — solely because there was (or at the very least, appeared to be) no viable open source alternative. This started at the very beginning, when the initial organizers needed a mailing list. Setting up a Google Groups list is free and fast; sadly the same cannot be said of any open source list service. If you have a server and can set up an instance of Mailman, you can create as many lists as you want — however, this is of no help before you have a domain name and a server itself. GNOME, KDE, GNU, and the various Linux distributions all host free mailing lists for their constituent projects, but at none of them can an interested party simply walk up and start their own list. Commercial services like Google and Yahoo offers this to any user; free software services like Mozilla Messaging, or perhaps Mailman itself with its highly-desirable list.org domain, are way behind.

Similarly, when it comes to collaborative work on documents, there is not yet an open source offering to compete with Google Docs. There are several collaborative text editors, but no spreadsheets — a vital need for budget tracking and program development. The TXLF team set up a MediaWiki installation (as is a common first step in any site launch), but wikis make for terrible collaboration tools. Wiki markup is, at its best, a weaker and ill-defined substitute for basic HTML, but more importantly, wikis are too often used as an amalgam for a public content management system (CMS), team task-tracker, and personal notebook. But they lack the access control, hierarchy, and editorial features of a proper CMS, and the real project-planning capabilities of a task management application.

There are several open source project management suites that a team could use to keep track of deadlines, deliverables, important documents (such as contracts), and contacts. Here again, though, most are behind the curve when compared to free software-as-a-service offerings, and in most cases the projects do not offer a free hosted solution at all. TXLF, like most volunteer projects, had to run its site on what we were given, a donated virtual host with only part-time support provided by a volunteer, and no choice over the application server or frameworks made available. It is easy to say "install it on your server," but without money and a systems administrator, that is rarely an option. Eventually, the TXLF group moved to tracking some multi-person tasks on Zoho, which offered the best compromise of features and limitations.

Perhaps these examples highlight something that the open source community rarely talks about: building tools for non-development tasks. If you intend to start a software project, you can sign up for free project hosting at a wide variety of services (from completely free software to those that are free of charge, but with closed code); you can get mailing lists, web forums, issue tracking, and release management. On the other hand, you do not get a customer (or "constituent") relationship management (CRM) tool, shared iCalendar service, or collaborative document editing. Moreover, if you want to start a project that does not involve code — say, design, documentation, or translation — you may not be eligible for an account at all.

Before working with TXLF, there were software applications I had only a tenuous awareness of; since the conference I have grown in appreciation for them. At the start, I managed all of my personal to-do elements for the event the way I do for writing assignments and other personal projects: with VTODO feeds organized within Thunderbird/Lightning. But that, of course, does not scale to multiple people, nor does it expose task dependencies or other tools to keep larger projects on deadline. While it is easy to keep in touch with a group on IRC, for large-scale projects one will eventually need collaborative document sharing and editing. Finally, while it seems simple enough for an individual to keep track of one year's sponsorship discussions via IMAP folders, that answer does not offer the flexibility of a CRM system, which multiple users can contribute to, and which multiple users can use to assist the project. The TXLF team did not find a document management or CRM system to use during the 2010 planning cycle; although Zoho worked well enough for multi-user task tracking, it offered neither of the other features; finding a free solution encompassing both is on the to-do list for next year.

Closing thoughts

Anyone considering starting an open source or Linux conference in their local area should take the plunge and do so; so long as you are comfortable scaling the size of the event to the number of volunteers and potential attendees in the area, it is within reach. Quite a few people I have met while wearing the "Press" badge at other Linux conferences have shared the opinion that these weekend-based, community-driven events are the wave of the future.

Unlike large-scale and corporate-run conferences, they tend to be very low-cost and draw on the ever-growing numbers of home-Linux-users and home-based-telecommuters. The odds are that if there is not already a regional Linux show close enough that you don't mind driving to it, there are other people in your area who feel the same way. Hopefully the FOSSEvents.org project will make it easier to start from scratch, assess the viability of such a project and make cost- and time-appropriate plans; if nothing else you know it has been done many times before and the community is willing to share its knowledge.

Progress on the tools front is probably a longer-term goal. I am aware that several of the larger-scale non-profit software projects are themselves grappling with CRM and document-management application selection, so the community recognizes the need. Building truly free web services is a topic getting increasing coverage in the press, blog world, and conference circuit, but it has not yet reached critical mass. Nevertheless, if we do not hang a shingle outside and offer to tell our neighbors about open source software, who will?