# Subject: Vendor Neutrality

To: [e-mail]

I have been thinking a lot lately about the issue of vendor neutrality, and how it relates to our brand at the ASF. We are often referred to in the press, and in discussions at various companies, as a vendor-neutral place where people (and companies) can collaborate on important software projects. This is a central part of our brand promise, and it's what we promise to companies that bring their projects to the Incubator.

But, increasingly, I am seeing projects that are very obviously dominated by one company. And I'm increasingly involved in conversations with various members about how to fix this.

But it's complicated. And the companies behaving in these ways are not always (or even usually) doing so out of malice.

We are business friendly. We encourage, with our policies and practices, companies to build businesses around our projects. We are not going to forbid $company from hiring 51% of the members of a PMC, nor are we going to forbid a particular PMC member from accepting a job.

Indeed, we've been having this conversation since way back in the earliest days of the Foundation when certain companies (Covalent, Joost, IBM, Red Hat, etc, etc) hired significant portions of the PMCs of certain projects.

There aren't any easy solutions. Or, rather, the easy solutions[1] (such as, for example, kick all employees of $company off of $PMC until they mend their ways) tend to have significant associated costs, both in reputation, and real actual financial harm to both individuals and companies. Solutions must protect all of the stakeholders in our projects, or they are not solutions.

This is further complicated by our "everyone is an individual volunteer" stance, which, while an important part of our philosophy, is also, of course, mostly mythical. The question of people's motivations in working on open source is complicated and nuanced, and, yes, obviously, a lot of (most?) people work on ASF projects because it's their day job. Pretending otherwise is a fantasy. (Yes, I know many of our most passionate members are, indeed, purely volunteers. That in no way changes the reality of the overwhelming majority of our participants on our most well-known projects.)

But we need to find ways to ensure that this part of our brand promise is maintained, if we want to continue to be the special and critical part of the free software landscape that we have worked so hard to be.

I suspect you all have a project in mind when you read the above. I suspect that your list overlaps, but is not the same as, my list. And I think that focusing on specific projects and companies will only serve to make this discussion more difficult, not less.

I've been hesitant to bring this up at all, for the usual reasons. I know that questioning the motives of people engaged in our projects can lead to personal attacks that derail the discussion into unwelcome and unproductive directions. But I am encountering this particular topic in so many different projects that we cannot afford to keep ignoring it.

What I'd like is a discussion around what boundaries are acceptable to the membership, to protect this aspect of our brand promise. And what practical solutions there are to this very real threat to our future.

## [1] Appendix A: Simple solutions

The cost of any "solution" is that companies will be reluctant to bring projects to us, or participate in projects here, because we ar acting in ways that limit their ability to profit from open source engagement, or leverage their particular value proposition on top of those projects. That, in turn, will reduce our relevance over time.

Solution: Kick people off of the PMC when a company demonstrates undue influence. (ToDo: Define undue influence.)

Cost: This will have a negative impact on that company's reputation, and possibly their stock price. It may also make other companies more wary of bringing projects to the ASF, or participating in projects, since we appear to punish success. It may also cause that company to withdraw entirely from the project and/or fork and go away, resulting in damage to that project's sustainability.

Solution: Limit the percentage of a PMC which can be from one company.

Cost: This is complicated. Are we going to tell a company they are not permitted to hire another member of that PMC? How would we enforce that? Are we going to tell a PMC member that they must turn down a job offer? How would we even do that?

## Other questions

What metrics can we use to define undue influence?

* Percentage of PMC (are we going to ask for affiliation?)
* Percentage of patches accepted
* Percentage of committers
* A pattern of block voting
* A pattern of slow-rolling or blocking contributions from other vendor's employees