The new struggles facing open source

The religious wars have faded, as new conflicts around control, code ‘sharecropping,’ ‘fauxpen source,’ and n00b-sniping arise

Business man woman pull rope tug of war cliff clouds struggle battle
Credit: Thinkstock

The early days of open source were fraught with religious animosities we feared would tear apart the movement: free software fundamentalists haggling with open source pragmatists over how many Apache licenses would fit on the head of a pin. But once commercial interests moved in to plunder for profit, the challenges faced by open source pivoted toward issues of control.

While those fractious battles are largely over, giving way to an era of relative peace, this seeming tranquility may prove more dangerous to the open source movement than squabbling ever did.

Indeed, underneath this superficial calm, plenty of tensions simmer. Some are the legacy of the past decade of open source warfare. Others, however, break new ground and arguably threaten open source far more than the GPL-vs.-Apache battle ever did.

How we got here: From purity to profit

The different sides used to be clear. Richard Stallman chaired the committee on free software purity while Eric S. Raymond inspired the open source movement.

Both sides rigidly held to their cause. And both sides draped themselves in a different licensing flag: GPL for the free software purists, BSD/Apache for the open sourcerors.

Not surprising, the increasing popularity of both camps stirred significant financial interest; thus, the profit motive came to open source. VCs prowled for projects with enough downloads to justify a support-and-service business model. Companies like Alfresco, JBoss, XenSource, and Zimbra sprang up to capitalize on the industry’s interest in open source, with developers increasingly wary of their be-suited new neighbors.

As these startups grew toward IPOs, however, the support-and-service model ran out of gas, as 451 Research analyst Matt Aslett warned. Then began the “open source plus proprietary add-ons” era of open source, with companies building “enterprise versions” of open source projects, withholding features for paid subscribers. The dreaded Open Core model was born, and the industry set out to tear itself apart over accusations of bait-and-switch and proprietization of open source.

The era of milquetoast open source

Excoriating fellow open source proponents on a grand stage over grand themes seems at this point a figment of the past. Infighting has become more contained, almost on a project-by-project basis. The GPL has steadily diminished in importance as developers have opted for the laissez-faire approach of Apache-style licensing. Commercial interests run rampant in open source. It’s how open source is done these days -- which may be the fundamental issue facing open source today.

As free software advocate Glyn Moody argues, a certain amount of tension in open source is desirable because a lack of tension “means people don't care anymore.” He’s right, but what belies this semblance of open source as a happy, if bland, family today is a shift away from passionate arguments about freedom and toward a more calculated conflict over control.

The rise of the company man

Control as a central issue for open source finds its roots in past debates over Open Core. While free sourcers and open sourcerors might have disagreed on the optimal license to guide a development community, both aligned on the need to keep corporate interests from controlling a project’s community. This mistrust of corporate influence over open source code persists to this day, but as it turns out, corporate influence -- and control -- is both a blessing and a curse.

Take a look at the latest Who Writes Linux report, for example.

Linux contributors The Linux Foundation

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.

Controlling the code

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.

Related articles

This story, "The new struggles facing open source" was originally published by InfoWorld.

To comment on this article and other CIO content, visit us on Facebook, LinkedIn or Twitter.
Download the CIO October 2016 Digital Magazine
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.