At 2:30 PM GMT on 11 September, five squares appeared on my screen and the launch deck almost immediately gave way to a real conversation. Around the room were a product preparing to open its doors, a pull request that had taken since 2024 to land and the familiar uncertainty of trying to find a way into an ecosystem as large as Kubernetes.
We came to launch the Stripe Open Source Community, but within the hour the individuals in the room had already shown us why it needed to exist.
With Dani and the wider team at Stripe helping us get off the ground, I brought one question from my work at DataJourneyHQ: how do we bring maintainers and businesses closer, so they can learn from each other and keep good open-source work alive? Their support gave us the room, and the individuals who joined gave it direction.
Four individuals, four ways into the same problem
Kamil J. was preparing to open the base layer of a product that connects Stripe with local accounting systems and wanted to understand both the network effects and the technical debt that can follow. Ali T. spoke from years of contributing about slow pull requests, invisible labour and the very practical need to teach individuals how to report a bug that someone else can reproduce. Tara G. knew the energy of DevOps communities but had also felt how quickly large ecosystems and dense documentation can make a newcomer feel lost, especially when the ways to contribute beyond code are hard to see. Manul P. brought us back to motivation and asked what funding, bounties, incentives and recognition might do to help contributors keep going.
Four different starting points led to the same truth: opening a repository is easy compared with creating the conditions for individuals to enter, contribute, be valued and stay.
What sits beneath the code
One image kept the conversation grounded: an iceberg with code at the top.
Beneath it sit maintainers, contributors, documentation, governance, funding, infrastructure, monitoring, security, network effects, technical debt and organisational culture. Those layers are less visible, but they decide whether a project can welcome individuals, respond to risk and keep going.
Instead of telling the room which layer mattered most, I asked two questions: which part is unfamiliar to you, and where should this community put its effort?
AI entered the conversation from both directions. Kamil had seen a Polish open-source project use AI throughout contribution and review, turning repeated work into something closer to a system. Ali wondered what happens to the value of open-source labour when the same technology makes it easier to recreate an idea without recognising the individuals behind it.
Both can be true. Contributors may gain speed while maintainers inherit more review, quality and communication work. The interesting question is not whether AI is good or bad for open source. It is how we use it without losing the human judgement and trust that make collaboration possible.
What the next rooms need to make possible
By the time we closed, the next couple of sessions no longer felt like topics on a list. They felt like two jobs this community should take on.
The first is to make it easier to find a way in through documentation individuals can navigate, reproducible bug reports, issues maintainers can act on and thoughtful use of agentic or non-agentic tools. The second is to make it possible to stay and grow well by sharing practical approaches to technical debt, security, network effects, funding and recognition.
That gives us a clear shape for what comes next: maintainers and builders opening up real projects, showing what they tried and speaking honestly about what worked, what failed and what another team could reuse. From there, members can decide whether the next step should be a deeper talk, a shared resource, a project clinic or something we have not imagined yet.
AI will run through both conversations because it can remove friction for contributors while quietly passing more pressure to maintainers. We are not trying to fill a calendar from the top down; we are building a useful loop where the community names the problem, practitioners bring the evidence and the next session grows from what we learn together.
The community will need more voices
As the community grows, we will be looking for more speakers, maintainers, builders and supporters willing to bring what they have learned into the room. That could mean opening up an open-source project, sharing how a company supports the work behind one or offering a hard-earned lesson on security, contributor tooling, funding or community building.
It does not need to arrive as a polished keynote. A practical demo, a case study, a failed experiment, a useful resource or one difficult question can all help this community thrive.
You can also visit the Stripe Open Source Community page to follow what comes next.
The first gathering did not give us every answer. It gave us something better: four honest perspectives, a set of questions worth returning to and a community willing to work through them together.
The room is open now. What it becomes next will be built by the individuals who walk in.