The Level Playing Field

Recently, in a Slack channel, Joe Pelletier asked a question:

Hey all, I wanted to get some feedback on how we might be able to improve our community processes for Feature ideas & brainstorming requirements. Awhile ago, I was reading about how other OSS Projects manage contributions, and came across this note from Mitchell Hashimoto about how they use GitHub Discussions vs. Issues.

I was wondering if other folks have worked in other Open Source communities where GitHub Discussions was used as a place to sort through Feature requirements/acceptance criteria before an issue was created, and if it was helpful (provided contributors with clearer direction) or had other side-effects.

I want to answer Joe’s question.

Let’s understand it first. He’s asking about OpenHands/OpenHands repository. That’s a hybrid of SaaS and Local GUI. It’s not an OSS project (the SaaS is not).

When Joe says “Open Source community”, I think he means “people who post issues and PRs on OpenHands/OpenHands”, which includes proprietary codebase users, Open Source codebase users, claws (and BillionClaws), humans who set off Cursor Agent or Claude Code on random popular repos on GitHub, just because they can, and people who don’t know how to call what they’re using. Frankly, it’s a mess.

But I think we have multiple scenarios here.

Scenario #1: Ghostty - Author Fixes his Workflow

Let’s look at the example Joe gives: Mitchell Hashimoto and Ghostty.

Mitchell built Ghostty after leaving HashiCorp, as a personal side project. He open sourced it under Apache 2.0 (similar to MIT), and the response from the community was overwhelming. He continues to work on it, and it’s a great project. (I use it.)

In that case, the project is Open Source. The author has built and offered to the world a piece of software that anyone can use, modify, fix and add to. If he wants to use GitHub Discussions for brainstorming on it, that’s his choice to make. The thing is, as he explains elsewhere, he was maintaining the project for years, and was fixing his workflow so that he can keep up.

Scenario #2: OpenHands - Managers Manage Contributions?

Now, let’s look at the OpenHands/OpenHands case.

Joe’s question is interesting for what it doesn’t say:

who will be “managing contributions” and “providing contributors with clearer direction”?

In my understanding of the question, Joe would. Joe is a good professional, and I’m happy to see him refine our understanding of what features people need. We’ve been quite lax before.

But you face an impossible task if you want to “manage contributions” for an Open Source project. That would mean: someone who doesn’t do the work having power over those who do. No no no.

That would crush the project. With the weight of a thousand suns.

No way.

Open Source contributors are not unpaid minions who follow orders, and surely not from people just “manage contributions” from the corporate ivory tower.

Maybe that works inside All Hands AI, but in Open Source projects it doesn’t.

Though it’s an early-stage startup of ~two dozen people or so, and I’m not so sure even there. As it happens, I was recently listening to a podcast with Ben Horowitz. He described a common pattern that early startups fall into and may never recover from: cascade from some fails, to founders becoming very open to consensus from the team, to founders deferring too much, and, eventually, giving too much power too early to employees who don’t do the work over those who do. It kills responsibility, ownership, and, he says, it wrecks companies.

I happen to believe that early-stage startups are a bit like Open Source projects on this one. Ownership is not just for a task, and not just for a ticket. It’s for a thing to happen, whatever tickets or no-tickets or roundabouts it takes.

Either way. I do know one thing for sure: in Open Source projects, the people who do the work have the ability to shape the project. And every PR is a proposal to the project. Maintainers may modify issues or PRs if, in their best judgment, they need to, even though they previously seemed like a good idea. That may even mean that older, well-thought-out requirements could need to change at any stage; though as far as I can tell, that’s not common.

Scenario #3: Authority Flows from Doing the Work

Now let’s run a thought experiment. Let’s say we finalize the move to the new repository layout, so please picture this:

OpenHands/OpenHands — the rebuilt OpenHands foundation (moved from sdk repo)

OpenHands-Web — the hybrid messy codebases currently there

Now. Say we’re looking at the restored OpenHands/OpenHands repo.

Let’s say Xingyao is like “ugh I have too many notifications, can we move the discussions to GitHub Discussions and only create issues for stuff totally ready to send the agent on?”

My response would be: “Sure, if you want.” There are trade-offs, as Ash pointed out, worth discussing. But nothing is fundamentally wrong with the idea itself.[1]

Sorry, Joe, and sorry, Ash. It’s not my intention to be harsh by any means; I do want to be clear, though.

That works for Xingyao. It doesn’t work for you.

Because in Open Source, authority flows from doing the work. If Xingyao wants to change how issues are organized, that’s a maintainer shaping their workflow.

---

Leadership of an Open Source project cannot possibly be “assigned” by corporate labels, whether that’s head of this and that or manager of the other. In fact, Robert cannot delegate it to you, Joe, or Ash, or Lila, because you cannot delegate leadership. Sure, I get he may have delegated some management of stuff or operations within All Hands AI, but that’s different and I strongly suggest that we interpret it as referring to the SaaS only.

I know we all have the best intentions, and you are most welcome to contribute to the project in your own way, just like anyone else is. You are great people and have been doing great work. This isn’t about whether product work has value — it does. It’s about whether any corporate role grants authority over the Open Source project. It doesn’t.

But the problem here is, the SaaS is not OSS, and I admit I was worried for a long time that the habits from working with proprietary stuff risk being applied to the Open Source project. That… is the problem here, I believe. And it would be a disaster if it was to move forward.

Maybe you can “manage contributions” from BillionClaws. You cannot do that with people dedicated to improving an OSS project to serve better their needs.

Nobody is going to spend their time to do unpaid work for “managers” or “the company”. No no no. That’s an incorrect view of what an OSS project is, and I hope you didn’t intend that, because frankly, it would come across as a bit insulting to the hundreds of contributors to the project. And it would turn it into a desert land, where, well, you can use the wrong metrics to tell yourselves that it looks sorta healthy, when in reality it has long been reduced to the company alone.

Maintainers are not “managers”, they are shepherds. They help people realize their own goals in the project, guide them to become, hopefully, long-term contributors; they make sure the project is moving forward towards its goals, benefitting them as well as any user relying on it (including users from AH or wherever). They don’t “provide contributors with clearer direction” — apparently from bureaucratic processes behind closed doors.

I strongly believe that Open Source projects are better when they can harness the power of the community, when they can benefit from insights and work from people looking to realize the vision behind it. This has many implications; for example, potential contributors need to trust the maintainers to do what they believe best for the project, and guide them accordingly. If maintainers become maintainers only in name, if they’re gradually or suddenly transformed into “code monkeys” merely implementing orders from people who don’t do the work, that will fail. It always does.

---

Addendum

The Wrong Metrics

I was actually telling Joe recently that AI PRs are cluttering the metrics. We’re using the wrong metrics to tell ourselves that the project is fine and healthy, when that is not quite the case.

For context, across all of GitHub there is more than a 10x increase in commits. Please think about that for a moment. Yes, AI agents make us all more productive; but the more important point here, it seems to me, is that many are AI PRs and issues that may not even have a human in the loop at all, or the human never used the project they claim to “contribute” to.

We surely know that humans need to take responsibility and make a first review of the AI output they authored; otherwise there is no authorship. There is no real help to the project. Popular Open Source projects are completely swamped and turning against AI because the contributions are low-effort, useless, and the maintainer workload has increased tremendously at low-to-no benefit to the projects.

They’re obscuring reality. The reality is that the OpenHands/OpenHands repo doesn’t have many contributions anymore that show human understanding and effort. Some, but far from what you’d think. The accounts posting PRs are not necessarily even people who use OpenHands.

Let me repeat that: human accounts posting AI PRs are not even using OpenHands.

There is no link between them and the project.

We make dashboards with “contributions” that give people a false sense of the project’s health.

I know, because I read most of these AI PRs, at various points in time.

Snapshot of reality

Last year, there were multiple patterns in my DMs and mentions. People were asking me stuff like, does OpenHands want to do x, or how we do y, or can I maybe run some small evals for them. Normal stuff for a core maintainer of the project.

This year… In recent months, I had in my DMs some questions I had never heard in the OpenHands project before. Basically, people were asking for my opinion on whether it makes sense for them to propose their enhancements to Web. Like, “does it make sense now, or is it too late, or too soon?” or “can I avoid the Saas?” or “who will review and will I get a fair hearing for what I’d like to propose in PRs to Web?”.

In other words, they were asking me if there is still a level playing field in OpenHands/OpenHands.

This is my honest answer:

• Yes, in the SDK
• ~Yes until a few months ago, but No since something broke - in the CLI
• No, in OH / OH.

I believe it’s essential for an Open Source project to keep a level playing field. That is, contributions should be judged on their merits, not on extraneous factors like their relationship to the company. It needs to be timely enough, too, to respect their time and so that people have context fresh in their minds and can build on previous work. Every use case they bring is worth proposing, evaluating on its merits, iterating on, and merging if it’s better for the project. Otherwise, they will not stick around, of course.

In OpenHands/OpenHands, I believe the level playing field is broken. I blame most of it on the SaaS influence at multiple levels. For a while now, I hear from people who don’t feel it’s worth proposing their work… which is a terrible consequence. It’s depriving the project of actual dedicated humans that could bring their expertise around, while fooling us with low-quality AI PRs that make up the broken metrics.

The path forward

I apologize for the confusion. I’ve been well aware for a long time that the unusual setups were very prone to it, though I didn’t fully realize how deep the problems go. I promise I will do better at clarifying licensing and all.

I do believe we will improve the situation by finalizing the repository layout. It means we will use the right name for the right thing. Web is Web. CLI is CLI. OpenHands is the Open Source foundation, in the shape of an SDK, that they are built on. We need to separate, a lot more than today, Open Source from proprietary, open processes from closed corporate processes, and restore the focus on the best AI software engineer for the people. You are welcome on this journey, like everyone else is.