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.”