The current state of conflicts in open source production and movements

Excerpted from Matt Asay:

“Corporate influence — and control — is both a blessing and a curse.

While 12.4 percent of development on the Linux kernel is done by unaffiliated developers, presumably out of the kindness of their hearts, most of the kernel is written by developers paid by Intel, Red Hat, and others. While I’m sure they would like to contribute regardless of a paycheck, the reality is that most can’t afford to write software for fun.

This principle applies to most any open source project of any significance. OpenStack? HP, Red Hat, and Mirantis combine for nearly 50 percent of all code contributions. Apache Software Foundation projects like Cassandra (Facebook, DataStax, and so on), Hadoop (Cloudera, Hortonworks, MapR), and others all depend heavily on corporate patronage.

Open source software, in other words, may be free to use, but it’s not free to build.

Still, some dislike the corporate influence for another, more troublesome reason. “I think pretty soon we’re going to see how bad it is when every successful [open source] project is backed by a company, most of which fail,” declares Puppet Labs founder and CEO Luke Kanies.

Kanies makes an astute point: A project may be very successful, but that won’t necessarily translate into a financial bonanza for its primary contributors. If the company owns the copyright and other intellectual property rights behind a project, then fails — well, the dot-org fails with the dot-biz.

That’s one major reason we’ve seen foundations become such a big deal. Foundations, however, are not without their issues.

* Cloaking corporate interests in foundational garb

In the past few years, foundations have become the vanity plate of corporate open source. While some companies successfully push code to a true community-led foundation (OpenStack comes to mind), others use foundations as a facade for “fauxpen source.”

One recent example is the Open Data Platform, which amounts to a gathering of big companies trying to fund Hadoop distributions that rival Cloudera and MapR. As Gartner analysts Merv Adrian and Nick Heudecker see it, ODP “is clearly for vendors, by vendors,” and they rightfully worry that “[b]asing an open data platform on a single vendor’s packaging casts some doubt on ‘open.'”

Not that ODP is alone in this. Plenty of foundations essentially serve the interests of a single vendor, whatever their ability to gather a few heavy-pocketed friends to go through the motions of “community.”

Like the OpenCore concerns of the first 10 years of open source, corporate foundations rub raw the free spirits in the open source world, because such foundations set up an asymmetric power structure. It makes little difference if copyright assignment flows to a single company or a foundation led by a single company, the effect is the same: The would-be contributor amounts to a particularly powerless digital sharecropper.

This isn’t the only tension in foundation land.

One of the primary reasons for going to a foundation is to make project governance open and predictable. Many projects, however, eschew governance or licensing altogether. The so-called GitHub generation has been happy to load the code repository with software of unknown licensing pedigree. While GitHub has been trying to reverse this trend toward license-free development, it persists.

Even where a license exists, GitHub “communities” stand in contrast to more formal foundations. In the latter, governance is central to its existence. In the former, relatively no governance exists.

Is this bad?

As Red Hat chief architect Steve Watt notes, “Obviously, the project author is entitled to that prerogative, but the model makes potential contributors anxious about governance.”

In other words, we don’t worry as much anymore about a project’s license, which was the way corporations would seek to control use of the code. Control of projects has shifted from the code itself to governance around the code.

But it’s not only The Man that makes open source a minefield.

With communities like this …

The final, and perhaps most entrenched, tension facing open source today stems from a problem we’ve always had, but which has become more pronounced in the past few years: The open source welcome committee is not always welcoming.

It has always been the case that some projects have leaders who can be fearsome to cross. Anyone who has had Linus Torvalds tell them, “*YOU* are full of bull—-,” knows that open source requires a thick skin.

But things have gotten worse.

No, not because project leads are increasingly rude or callous, but because there are far more newbies in any given project. As one HackerNews commenter notes, “[S]mall projects get lots of, well, basically useless people who need tons of hand-holding to get anything accomplished. I see the upside for them, but I don’t see the upside for me.”

Dealing with high volumes of would-be contributors with limited experience strains the patience of the best of leaders, and well, sometimes those leaders aren’t the best, as this broadside from OpenLDAP’s Howard Chu shows:

If you post to this list and your message is deemed off-topic or insufficiently researched, you *will* be chided, mocked, and denigrated. There *is* such a thing as a stupid question. If you don’t read what’s in front of you, if you ignore the list charter, or the text of the welcome message that is sent to every new subscriber, you will be publicly mocked and made unwelcome.
As one example, half of all contributors to the Linux kernel in the past year are new contributors. This same phenomenon is playing out across the industry, and “Newbies Not Welcome!” signs like Chu’s aren’t a great way to accommodate the influx of those who want to participate but don’t yet know how.

Ultimately, open source isn’t about code. It’s about community, and as Bert Hubert suggests, “community is the best predictor of the future of a project.” That community isn’t fostered by jerk project leads or corporate overlords pretending to be friendly foundations. It’s the heart of today’s biggest challenges in open source — as it was in the last decade.”

1 Comment The current state of conflicts in open source production and movements

  1. David Week

    It’s much easier to describe what community should not be than to describe a positive model for community. Matt Asay does the former well (and dispels some myths in doing so), but glosses over the latter. I suspect that for many, “community” is an empty signifier, a marker for an undefined but desired ideal, characterised more by an absence of problems than a specific form.

    I’m with the anthropologists and the sociologists who would say that all of the above negative examples are also “community”—just of different types. I see in the story of Torvalds the story of any “president for life”, who after a while ceases to see any need to be civil—and in some cases, even humane. Who will topple him? Who will vote him out? In the case of Chu, I see mirrored France’s National Front and the UK’s UKIP: people who are rendered so anxious by the influx of foreigners, and the short term demands they make on the local economy, that they become xenophobic and impose immigration controls.

    There are many forms of community and governance with which we have become disenchanted. Some new forms have been been proposed, mostly in the forms of sets of rules and constitutions. I think that such documents are useful tools for communities, but not essential. They are, after all, a fairly new inventions. Much older is the cultural image of the governors. Ordained by God? Programming prodigies? I suspect that any community that cloaks its governance workers with hopes of excellence, and adorns them with wealth and privilege, whether gold crowns or corporate jets or tolerance of assholiness, is following the same cultural model, and will re-create the same form of community.

    An alternative might be to see governance as boring, stressful, dirty work that someone has to do, and is absolutely necessary to society: like, say, the sanitation worker. Such governance workers would not have high salaries, have no perks of office, and (if they are working well) be rarely reported in the press, precisely because they do their jobs well, and therefore require no comment. Their work would be 90% listening, 9% synthesising and checking what they’ve heard, and 1% action. Speeches and sound bites would be a thing of the past.

    Part of this equation is exemplified by Evo Morales. I suspect that Morales’ behaviour was informed by his experience as an indigenous person, a place we might be look to for lessons (but not models) of governance. We have to invent what we want to see.

Leave A Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.