The future of first-party open source events

A group of people with laptops sitting around a rectangular wooden table.

In this post, I’m discussing only first-party open source events — events run by a project for its contributor and/or user communities. Third-party events like regional or industry conferences are a separate matter that I may or may not write about later.

There’s a long history of large open source projects hosting first-party events — contributor conferences, user meetups, and the like. Some subset of the community gets together and talks about all of the cool things going on in the project. They plan work and make decisions about the future of the project. And the way they’re typically setup does not fit the world in 2024.

The old way

The current model made sense in a time when virtual gatherings were difficult or impossible. The only way to have synchronous, high-bandwidth communication was to get people into the same room. The social activities — planned or serendipitous — improved the fabric of the community by helping members bond as humans. But these gatherings were always exclusionary. Attendance was a privilege that many did not have, due to travel funding, visa issues, family care obligations, et cetera.

When the COVID-19 pandemic forced events online, the social value was diminished. Hanging out on a conference platform is not as connected as sitting down together over lunch. But the inclusivity went way up. For example, the 2022 Nest With Fedora had nearly four times as many attendees as the most well-attended iteration of its in-person counterpart, Flock to Fedora. People who never could have attended in person were able to participate, and it helped the community grow into new areas. It’s not perfect, of course, as geographical limitations give way to time zone limitations and travel & care-giving limitations give way to technology limitations.

Many communities have returned to their old in-person model, perhaps with some live streaming thrown in for remote attendees, in the last couple of years. But I think that’s more from inertia than anything else. If we were starting today, we would not design what we have.

Pandemic lessons

We learned during the acute phase of the pandemic that online events, when well-managed, can be a very effective way of delivering presentations to a broad audience. Many event talks fall into this category: “what’s new in _”, “state of _”, and so on. These don’t require a high degree of interactivity; they’re primarily the speaker delivering information to the audience. They have value, but don’t need in-person interaction. In my experience, doing these as hybrid sessions, with some attendees in the room and some online, is generally an unpleasant experience for the online attendees.

By the same token, we learned that entirely-online events make it harder to develop deep social bonds. They also are unpleasant for brainstorming, design, and vigorous debate. When the Fedora Council had to switch from a multi-day, in-person hackfest to a multi-day, online hackfest, it went from tiring-but-productive to excruciating.

The way forward

There’s no perfect solution, but if I were designing first-person open source events today, I’d have three categories: talks, social, and workshops.

Talks

Talks events would be the “a speaker presents to the audience” type. These would be held entirely (with one exception below) online for maximum reach. Attendees watching live could ask questions during or at the end, and there would be a window (a week, say) for asynchronous Q&A so that people who have to sleep or do other life things during the live broadcast can participate. A bold project might choose to forgo the live questions entirely and have only the asynchronous option.

As an exception to the online-only aspect, I could see local groups getting together for a watch party that doubles as a social event. But the point is that they’re not in the room.

Social

Social events are local gatherings where members of the community can connect. The travel distance depends on the community density, but in the ideal case, it’s a day trip. This means people don’t have to pay for hotel rooms and it’s generally easier to put the rest of life aside (of course, for some, even a single day is difficult to arrange). These events might have some informal talks about matters of local interest, but the general idea is to promote human connection.

Workshops

The final category is the only one where I’d expect any meaningful travel to occur. These events bring people together from wherever they are to work on something specific. This could be a strategic plan, and new website, documentation cleanup, or any number of things. The point is that they have a clearly-defined, specific outcome. This outcome should be something that can’t easily be done remotely. It should be easy to tell after the fact if the attendees achieved the desired outcome.

The problems with the way forward

I told you there’s no perfect solution, and you’ve probably picked up on a few things already. One of the big concerns I have with my plan is that the social connections are geographically (in the case of social events) or functionally (in the case of workshops) siloed. Colocating several workshops can help with this. For example, if the QA team meets up to develop a new automated test suite at the same time and place as the website team meets up to build a new web application and the documentation team meets up to migrate to a new publishing platform, attendees from all three groups can mingle during breaks and meals. Not everyone who should join a workshop can attend for the same reason they couldn’t attend a status quo event, but they’ll at least not miss out on the talks.

Another issue is that there’s less opportunity for networking, especially with the project leaders. The ideas that spring up in serendipitous hallway conversations can’t happen if people aren’t in the hallways. I don’t have a pat solution for this one. Some online event platforms have a general chat not tied to a specific section, and that helps, but it isn’t the same.

Despite these problems, this approach helps broaden the community’s reach and brings people in who couldn’t participate before. It conserves the project’s limited travel funds (if any!) for travel that has a well-understood — and, critically, easier to defend to the budget holder — outcome. On balance, it seems to be the least-bad of all options.

This post’s featured photo by Christina @ wocintechchat.com on Unsplash.

Ben formerly led open source messaging at Docker and was the Fedora Program Manager. He is the author of Program Management for Open Source Projects. Ben is an Open Organization Ambassador and frequent conference speaker. His personal website is Funnel Fiasco.

Share

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.