I just wrapped Snowflake Summit—four days, 20,000+ attendees, wall-to-wall product announcements and customer stories. It was a vendor conference. So why would I mention it here?
Well… open source was everywhere. Not just in the spaces we’d built for it, but in the hallways, across the expo hall, and in conversations I didn’t expect to have.
This was actually our second year building dedicated open source programming into Snowflake Summit, and we expanded significantly from last year. We were given more space with more projects represented, and we planned more structured activities. We learned a lot about what works—and what the community actually needs from a space like this. Some of it confirmed my instincts and some of it surprised me.
A Personal Aside. On Dev Day, I was emceeing and introducing our headliner speakers who were there to present practical insights into AI and what they’re building—not open source.
One of them recognized me from the Jupyter events I’d been attending. Despite not having interacted with him directly before, we had an immediate connection knowing that we both cared about the open source project. That we both knew the same folks. That we both got it.
This was out of the blue. At a Snowflake conference.
It was a reminder to me that the open source community is woven through the entire technology industry. It doesn’t stay neatly inside community conferences. It shows up wherever technologists gather. And these folks will make themselves known.
What we built
This year we had a dedicated open source area at Summit with programming covering much of our open source footprint. But the space was designed around hands-on activations—committer workshops for Apache Iceberg™, Apache Polaris™, TruLens, and Apache Spark™, onramps to Streamlit using AI tools, and fun, light activity sheets around our team’s favorite open source projects.
The idea was to give attendees a place to sit down, engage with our open source DevRel team, and get access to the Snowflake engineers building these projects.
What actually happened
The hands-on activities worked fine—over the week, we scanned around 400 people through our area and interacted with many more. But the moments that mattered most were the ones we didn’t plan for.
People showed up wanting to learn. They had questions about the projects, about how to get involved, and about what the roadmap looked like. They weren’t necessarily there to write code that afternoon. They wanted to understand. When they found out an expert was on-site, they were excited to get face time with maintainers. They wanted to know that there was a community behind these projects and that they could be part of it.
The maintainer tables—which were honestly hard to advertise within the broader expo hall during the week—turned out to be quietly effective. The people who found them (or we directed toward them) hung out. Some of our existing community members used the area as a gathering place to recharge between sessions and catch up with people they knew from other contexts. And some folks who wandered over just looking for a seat found themselves in conversations with my team about open source.
The space became something we didn’t fully design: a low-pressure environment where people could encounter open source at whatever depth felt right for them. Some came with specific technical questions while others came because they were curious.
What I’d do differently
Advertise the maintainer presence more clearly. “Come talk to Iceberg maintainers” is a more compelling draw than “hands-on OSS challenges.” We underestimated how much people just wanted access and the chance to ask questions and be heard by the people building the project.
Design for conversation first, hands-on second. Structured activities have their place, but they shouldn’t be the default assumption. Most people at a vendor conference aren’t ready to submit a PR—although I’d love to change that. Instead, they’re ready to learn, connect, and figure out where they fit. Meet them there.
Make the space findable and consolidated. Dedicated OSS space only works if people know it exists and know where to go. We had open source references scattered across a few different areas of the conference, which meant attendees weren’t always sure where to find our team’s open source space. Next year: one clear hub, more signage, more mentions in keynotes and session intros, and clearer way-finding should do the trick. The people who found us ended up having a good time. Too many probably walked past without knowing what was there.
The broader point
If your company runs a vendor conference and you’re not creating intentional space for open source, you’re missing an opportunity. Your community is already there in your customer base and your attendee list. They’re finding each other in hallways whether you facilitate it or not.
Vendor events are actually uniquely valuable for this: at a community conference, the content is already deeply technical by default. At a vendor conference, that’s not necessarily true across the board, so people are hungry for something different. They want to ask deeper questions in a context where most content is product-focused. The appetite exists precisely because it isn’t the default.
If you do create the space, hold your assumptions loosely about what it should look like. We designed ours for hands-on activities, but the community wanted presence, access, and a place to gather and feel like the open source part of their identity was welcome at a product event.
Dedicated OSS space at a vendor conference is worth investing in. And once you have it, let the community tell you what it needs to become.
I write about open source engagement strategy, community dynamics, and what it actually takes to do this work well. Subscribe if you want to think more deliberately about how your company shows up in open source.