OpenClaw 爆火后：维护者如何应对 AI 贡献与安全挑战

What began as a personal experiment quickly became a global open source project with extraordinary momentum.

OpenClaw is a personal AI assistant that runs on users’ devices and connects with the messaging channels they already use. Started by Peter Steinberger as a weekend project in November 2025, its GitHub repository has grown to approximately 388,000 stars, 81,000 forks, and more than 80,000 commits by August 26, 2026.

In this video interview, filmed just six months into the project, creator Peter Steinberger and several OpenClaw maintainers discuss managing a surge of pull requests, rethinking contributor trust and code review, addressing software supply chain risks, and balancing powerful agent capabilities with security. They also share security lessons from the GitHub Secure Open Source Fund and the value of connecting with maintainers facing similar challenges. Watch the full video above, then explore the key lessons below.

People in this video

The following maintainers shared their experiences maintaining and securing OpenClaw.

• Peter Steinberger, Creator of OpenClaw
• Brad Groux, CEO, Digital Meld
• Josh Avant, Member of technical staff, OpenClaw Foundation
• Josh Lehman, Martian Engineering
• Sally O’Malley, Principal software engineer at Red Hat
• Val Alexandar, OpenCoven
• Vincent Koc, Chief architect, OpenClaw Foundation

Here are the top 10 lessons that we took away from the conversation.

Lessons 1–3: How AI changed contributions and community

1. Pull requests became prompt requests

OpenClaw’s maintainers found themselves managing thousands of pull requests and issues, with some contributors opening hundreds of pull requests at once.

I don’t even call them pull requests. I call them prompt requests.

Peter Steinberger

There were some contributors that had multiple hundreds of pull requests running these sort of automated software factories that were just mining everything for issues.

Josh Lehman

The challenge shifted from attracting participation to finding valuable contributions amid a flood of activity that could overwhelm human review.

2. Keep the door open for new contributors

OpenClaw’s maintainers wanted the project to be welcoming to new participants, whether they were first-time open source contributors, non-developers solving a specific problem, or people using AI agents to help. Rather than dismissing imperfect contributions, they looked for promising ideas and worked with contributors to refine, rewrite, or complete the final changes themselves.

I know how it felt when, many years ago, my first pull request was accepted on a project.

Peter Steinberger

Some of the first-time contributions that were merged came from people without a development background. They used an agent to create a pull request, and worked with maintainers to finish the change.

A good proportion of those first-time pull requests that got merged are from non-developers. They’re just people that have a specific problem and a need.

Vincent Koc

3. Agents save time but make it harder to sign off

The maintainers described two very different outcomes from the same technology: agents can help people reclaim time, but they can also make it harder to stop working.

I’ve seen the other side of it, where people are just so in love with it and they realize, wow, if I don’t sleep tonight, I can do what used to take a week for me to do.

Val Alexandar

I have three kids. They’re very small. OpenClaw lets me manage agents that go and work for me so I can get back to playing with my kids.

Josh Lehman

Sometimes the maintainers will go on the channel and say, ‘I’m going to touch grass now. I’m taking a few hours off.’

Sally O’Malley

Agents are neither good nor bad for work-life balance. But they amplify both the opportunity to do more and the importance of knowing when to step away.

Lessons 4-6: How maintainers adapted

4. Earn trust by finding where you can add value

There was no single path to becoming an OpenClaw maintainer. Some contributors arrived through security work, others through integrations or community participation, but the common thread was finding a way to add value and taking ownership.

Peter ignored me, so I was like, how else can I get his attention? Security.

Vincent Koc

I’m a Microsoft guy, so I thought, is there a plugin for Microsoft Teams?

Brad Groux

I looked into the community and I was in voice chat, and people were asking a lot of questions, and I was like, well, how can I add value in these conversations?

Val Alexandar

5. The new trust signal is showing your work

As contribution counts became less informative, the team identified evidence that could help a pull request stand out: agent transcripts, screenshots, testing, and an explanation of the contributor’s thinking.

If you provide us with the transcripts, we actually see how you came to the pull request and your discussion with the agent. Incredibly valuable. If you add screenshots, you can prove that you tested this.

Peter Steinberger

The important question was not simply whether a human or an agent wrote the code. It was whether the contributor understood the feature and had considered how it interacted with the rest of the project.

Nobody cares if you wrote the code or not, but we care if you actually thought about this feature.

Peter Steinberger

6. Maintainers are reviewing agent code with agents

Maintainers increasingly relied on AI tools to help review AI-generated contributions, while also taking a more hands-on approach to improving submitted code.

Whenever I get a pull request from an AI, one thing I love to do now is use GitHub Copilot for all the reviews. I just press a button right there. It does a review and generates clarity on all the files that are attached, what the files mean, and how they changed.

Val Alexandar

This is the first project where I saw it become normalized that when someone submits a pull request, as a maintainer, you just edit it. You just make it right.

Josh Lehman

Lessons 7–9: Security challenges

7. Reputation became an attack surface

Contribution history itself could be manipulated. OpenClaw’s maintainers saw people duplicate existing pull requests, and Vincent Koc explains why.

People would basically duplicate other people’s pull requests. What they were attempting to do here was to build credibility, because we had these badges, like how many you’ve merged. So the more merges you had, it was like a trust signal to us maintainers.

Vincent Koc

Peter described a company using an automated pull request to promote their product. The team had to identify duplicate work and determine which pull request was the original.

The code was not the only thing the project needed to evaluate. Maintainers also had to reconsider the social signals they used to decide what, and whom, to trust.

8. “Safe by default” depends on who you ask

What feels safe to one user may feel unnecessarily restrictive to another.

The tradeoff was clear in practice. Tighter workspace restrictions generated user complaints, while fewer restrictions could expose the project to security incidents.

It’s really often a hard game to find the right balance between making it really convenient for users and also building something that is safe enough as a default.

Peter Steinberger

Secure defaults must account for an agent’s capabilities, what users understand, and what a particular environment is prepared to allow.

9. Know who maintains your dependencies

Recent supply chain attacks pushed the maintainers to think more carefully about both the dependencies they relied on and their relationship with the projects behind them.

We went through our dependencies with a fine-tooth comb. What it’s pushed us to do is actually reduce the core dependencies, but also create a relationship with the maintainers that we have a dependency on.

Vincent Koc