Create the Space
They're waiting to show up.
Yesterday I attended a Jupyter AI Developer Summit. And it reminded me, again, why in-person community events are one of the most underrated tools in open source.
Before I get into things, I just want to say that the Jupyter community has figured something out. They get together frequently—for sprints, for showcases, for developer summits. They have a solid technology that they’re excited to evolve. And they make sure the people building the project can be in the same room as often as it makes sense. At the same time, they’re genuinely welcoming to newcomers in any of these formats. It’s not a closed club. It’s an open invitation to participate.
As a bit of backstory: I first encountered the Jupyter community years ago while I worked at Bloomberg. And the energy of watching contributors come together stuck with me. It stuck with me enough that when I encountered the community again at Snowflake, I knew I had the opportunity to try to bring that same energy to other projects.
The question was: how?
You can’t copy the format. You can carry the intent.
When I started thinking about how to grow the contributor base for Apache Polaris™, Jupyter was on my mind. I’d seen what worked: a structured event, in-person, where contributors tackle open items together over a day or two. So we started hosting Polaris sprints with that general shape in mind.
But the community had other ideas—and that’s the point.
What we expected to be a “here are open issues, go sprint!” format evolved into something different. The Polaris contributors wanted to discuss high-level roadmap items. They formed breakout groups. They ideated. And given the governance model under the Apache Software Foundation, contributors needed to ensure that major discussion points were appropriately summarized on the dev list and discussed formally by the broader community afterward.
So we adapted.
The core of the event stayed in-person—because sometimes developers just need to be in the same room to have the conversations that move a project forward. We also offer a virtual component (Jupyter does this too). But the format became what the Polaris community needed it to be, not a carbon copy of what worked elsewhere.
That adaptation is exactly what I mean when I talk about playbooks being non-transferrable. The energy transfers. The intent transfers. The format doesn’t—and shouldn’t.
The appetite is there if you create the space
More recently, as I’ve worked more closely with Holden Karau at Snowflake on interacting with the Apache Spark™ community, we saw a similar opportunity. Could we bring people together to contribute?
We started with a “new committer workshop” at a Women+ in Open Source event—a focused, supportive environment where folks could learn the mechanics of contributing to open source projects like Spark. Then that idea morphed into a more general sprint-style event with a broader audience in Seattle later that week (which had great attendance given it happened in the middle of a snowstorm).
The takeaway from both: a lot of people are interested in engaging with open source projects if you give them the space and the support. They want to contribute. They want to be part of something. But the barrier to entry—finding the right issue, understanding the contribution process, feeling like you’re welcome—is often what stops them. Creating a structured, in-person space removes those barriers in a way that documentation alone can’t.
Why in-person matters…
I want to be specific about why the in-person piece is important, because I don’t think it’s just a “nice to have.”
Virtual contribution is how most open source work gets done day-to-day. That’s not changing. But there’s something about being in the same room that unlocks a different kind of collaboration:
Decisions happen faster. A governance discussion that would take two weeks of async mailing list threads can resolve in an hour when people are face-to-face.
Relationships form. Contributors who’ve met in person are more likely to review each other’s PRs, more likely to give benefit of the doubt, more likely to stay engaged long-term.
Newcomers feel welcomed. Walking into a room where someone says “here, sit with me, I’ll help you get set up” is fundamentally different from reading a
CONTRIBUTING.mdfile alone.Energy compounds. There’s a momentum that builds when a group of people are working toward the same goal in the same space. It’s motivating in a way that solo async work isn’t.
Jupyter understood this early and built it into their community culture. The sprints, the showcases, the summits—they’re not extras. They’re core to how the project functions and grows.
… and why it’ll matter even more.
As AI becomes increasingly capable of writing code, reviewing PRs, and triaging issues, there’s a temptation to think community engagement becomes less important. The opposite is true. The mechanical work of open source may get automated, but the human elements can’t be. We’ll still rely on trust, shared vision, and the relationships that form when people work toward something together. If anything, the rise of AI in open source makes these in-person, human-centered moments more critical. They’re what will distinguish a living community from a repository with automated contributors.
What I’d encourage
If you’re working in an open source community and wondering how to grow engagement, consider this: what would it look like to bring people together in-person? It doesn’t have to be a big conference. It could be:
A one-day sprint co-located with an existing event
A roadmap discussion with core contributors in the same room
A newcomer workshop where experienced contributors pair with first-timers
A showcase where people demo what they’ve been building
The format will depend on your community. Let them shape it. But create the space. Make the invitation. See who shows up.
You might be surprised how many people were just waiting to be asked.
If you’ve run contributor events, e.g. sprints, summits, workshops, I’d love to hear what worked and what didn’t. Drop a comment or reply to the email.
And if this resonated with you—subscribe. I write about open source engagement strategy, community dynamics, and what it actually takes to do this work well.