July 20, 2013

The Future Of Linux Evolving

The future of Linux: Evolving, everywhere

Serdar Yegulalp
 
July 15, 2013 (Infoworld)
Mark Shuttleworth's recent closure of Ubuntu Linux bug No. 1 ("Microsoft has a majority market share") placed a meaningful, if somewhat controversial, exclamation point on how far Linux has come since Linus Torvalds rolled out the first version of the OS in 1991 as a pet project.
Microsoft may not (yet) have been taken down on the quickly fading desktop, but the nature of computing has changed completely, thanks in large part to Linux's rise as a cornerstone of IT. There's scarcely a part of computing today, from cloud servers to phone OSes, that isn't powered by Linux or in some way affected by it.
But where from here? If Linux acceptance and development are peaking, where does Linux go from up? Because Linux is such a mutable phenomenon and appears in so many incarnations, there may not be any single answer to that question.
More important, perhaps, is how Linux -- the perennial upstart -- will embrace the challenges of being a mature and, in many areas, market-leading project. Here's a look at the future of Linux: as raw material, as the product of community and corporate contributions, and as the target of any number of challenges to its ethos, technical prowess, and growth.
Linux: Bend it, shape it, any way you want it
If there's one adjective that sums up a significant source of Linux's power, it's "malleable." Linux is raw material that can be cut, stitched, and tailored to fit most any number of scenarios, from tiny embedded devices to massively parallel supercomputers.
That's also been one of Linux's shortcomings. Its protean nature means users rarely use "Linux" -- instead, they use a Linux-based product such as Android, or a hardware device built with a Linux base such as an in-home router. Desktop Linux's multiple (and often incompatible) incarnations winnow out all but the most devoted users.
"How end-users experience Linux is definitely fragmented," admits Jim Zemlin, executive director of the Linux Foundation. "But that's one of the powers of Linux.
"It's a building block that has allowed Google to build Android and Chromebooks, Amazon to build the KindleCanonical to build Ubuntu, and much more. All of those experiences are different for the user, but there is choice for the consumer."
Mark Baker, Ubuntu Server product manager for Canonical, which leads the Ubuntu project, puts it in almost exactly those words: "Open source delivers freedom of choice." Open source naturally encourages modularity, he says, so "with open source you can choose the best components for your situation," whether you're a user working on a home machine or a systems architect developing a data center.
But Al Gillen, program vice president for system software and an analyst at IDC specializing in operating environments, questions the value proposition of such total freedom going forward. "Linux is open source, and as such, anybody can fork off code and turn it into something else. However, the industry has shown that forks without value go away, and there is great value associated with staying close to main line code."
Android users have experienced this most directly with the fragmentation that exists between different editions of the OS. None of that is, strictly speaking, Linux's fault, but as with the myriad desktop distributions before it, Android fragmentation illustrates the tension that arises between allowing the freedom to change the product and the fallout of inconsistency of implementation.
Ironically, that might mean the best thing for Linux, going forward, is to double down on Linux as raw material.
Eric Sammer, engineering manager at Cloudera, doesn't see Linux alone as having users "the same way as something like Firefox or the Apache Web server." Linux "is targeted toward operating system builders, not the end-user," and so it needs "tons of other software -- much of it tightly coupled, from a user's perspective (such as a boot loader) -- to form a complete system." As Torvalds himself noted in the release notes for the very first Linux kernel, "A kernel by itself gets you nowhere."
Both Gillen's and Sammer's words are echoed by how Linux's biggest uptake with users has been, again, Android, with all its attendant value added by Google and the app ecosystem developed for the OS. The malleability of Linux is only a first step toward an actual product -- as its most successful advocates understand.
Corporate contributors: Asset or obstacle?
Another of Linux's hallmarks is that it's a collaborative effort; out of the contributions of many come one. But where are those collaborators coming from?
Answer: Corporations -- mainly, those who stand to benefit themselves from supporting Linux for their own future endeavors. Aside from Red Hat (apart from Canonical, the most widely recognized corporate vendor of Linux solutions), top contributors include Intel, IBM, Texas Instruments, and even Microsoft.
Much of Linux's flexibility is due to such contributions, which expand Linux's ability to run on multiple platforms and on a broad spectrum of devices. Enlightened self-interest is the main motive here: Microsoft's own kernel additions, for instance, largely revolve around allowing Linux to run well under Hyper-V.
Sammer believes the prevalence of corporate-backed contributors is "due to the barrier of entry to any project as complex and critical as the Linux kernel. Your average C hacker doesn't have the time to get up to speed, build the credibility with the community, and contribute meaningful patches in their spare time, without significant backing." In his view, corporations most often have the resources to support such endeavors, with universities and research organizations being further behind.
But has the prevalence of corporate contribution to Linux turned the OS into a mere corporate plaything? Is that Linux's future, to be a toy of the monoliths?
What matters most is not who's contributing, but in what spirit. Linux advocates are firm believers in contributions to Linux, no matter what the source, as a net gain -- as long as the gains are contributed back to the community as a whole.
Mark Coggin, senior director of product marketing for Red Hat Enterprise Linux, believes "the best innovations are those that are leveraged, and improved by the greatest number of participants in the open source community."
"We put all of our innovations into open source projects, and seek to gain acceptance by those upstream groups before we incorporate them into our supported products like Red Hat Enterprise Linux. We hope that everyone who works to enhance the Linux kernel and the userspace projects also takes a view like ours," Coggin says.
It's also not widely believed that corporate contributions are a form of "hijacking Linux," as Gillen puts it -- a way to make Linux "less applicable to other major user contingents." He's convinced commercial support for Linux and commercial enhancements to Linux "are an asset to the Linux development paradigm; not a negative."
Likewise, to Zemlin, Linux development "is not a zero-sum game."
"What one developer does in the mobile space to improve power consumption can benefit a developer working in the data center who needs to ensure their servers are running efficiently," says Zemlin. "That shared development is what makes Linux so powerful."
Corporate contributions are not the enemy to him, either: "Having people paid to work on Linux has never been a bad thing; it has allowed it to be iterated upon quickly and innovation to be accelerated."
The real issues, as Baker notes, come when "some very large Web companies make some changes available and push them upstream, but decide to keep others in-house to give them an advantage."
Version 3 of the GPL -- the license Linux was released under in an earlier version -- was developed in part as a response to such behaviors. However, it only prevents taking code others have written and redeploying it as a Web service. There's no inherent (or legal) way to prevent code developed in-house from being kept in-house -- which might well simply be part of the ongoing social cost of offering Linux freely to the world.
The biggest threats to Linux
If corporate co-opting is less likely than ever, thanks to the mechanisms that keep Linux an open project, what real threats does it face?
Nobody takes very seriously the idea that Linux is about to be wiped off the map by a rogue patent threat or lawsuit. One of the biggest such legal attacks, SCO Group's lawsuit against IBM, widely construed as a proxy attack on Linux, failed miserably.
Coggin is of this mindset: "Linux's huge success, with a vast network of developers and widespread global adoption, means that it is highly resilient. Although patent threats arise from time to time, as they do with many technologies, it seems unlikely that a patent or combination of patents could pose an existential threat to Linux."
Plus, competition in the form of other closed source products, or even those with more liberal licensing (such as the various BSDs), hasn't really materialized to the degree that Linux runs the risk of being pushed aside.
Sammer sums up the biggest legitimate threat to Linux in a single word: complacency -- the complacency that goes with becoming a market leader in any field.
"If you're vying for first place," he says, "you're usually more open to change of process, of mindset, of road map, of status quo, whatever. I can't help but think of Firefox losing so much to Chrome so fast, or the commercial Unixes losing to Linux, or all the other examples of such things."
In roughly the same vein, Zemlin sees a threat in the form of a lack of experienced Linux talent to support the demand; hence the Linux Training program.
Gillen sees a threat coming from a transition that "over time, moves the majority of the Linux user community from the enterprise customer over to service providers."
Such a move would put Linux users at the mercy of people who may consume Linux and provide it as a service but don't return their innovations to the community as a whole. It may take a decade or more for such a shift to happen, but it could have "negative implications for Linux overall, and to commercial vendors that sell Linux-based solutions."
Another possible threat to Linux is corporate co-opting -- not of the code itself, but of the possibilities it provides. Baker is worried about the rise of mobile devices, many of which, although powered by Linux, are powered all the more by corporate concerns.
"That's why we need alternatives like Ubuntu and Firefox," says Baker, "to provide real alternatives for those who do not want their experience of the Internet to be determined by Apple or Google."
Of those two, Google -- by way of Android -- is the main offender in this accusation. Many of the arguments against Android revolve around it being a Linux-powered OS that's little more than a portal to Google's view of the world, and thus isn't true to the spirit of Linux.
In short, the biggest threats to Linux may well be from within -- unintended by-products of the very things that make it most attractive in the first place. Its inherent mutability and malleability has so far given it an advantage over complacency and co-opting, but it isn't clear that will always be true.
Where from here?
Linux is unquestionably here to stay, and in more than one form. But how it will do that and at what cost are up for debate.
The most obvious future path for Linux is where it becomes that much more of a substrate for other things -- a way to create infrastructure -- and where it becomes that much less a product unto itself in any form. The real innovation doesn't just come from deploying Linux, but deploying it as a way to find creative solutions to problems, by delivering it in such a way that few people are forced to deal with Linux as such, and by staying a step ahead of having it put behind technological bars.
Coggin puts it this way: "Linux is emerging beyond that of a packaged or flexible operating system to become more of an infrastructure platform. With this, we see developers and architects using Linux to build next-generation solutions, and creating next-generation enterprise architectures." Much of this work is already under way, he claims, in "cloud, big data, mobile, and social networks."
Gillen, too, agrees that Linux "is going to be a very key part of public cloud infrastructure, and as such, it has ensured itself a long-term role in the industry."
"Linux already runs the cloud, of that there is no doubt," says Baker. "It needs to maintain its position as the platform for scale-out computing -- this means staying ahead of new technologies like ARM server chips and hyperscale, software-defined networking, and the overall software-defined data center." Such work ought to complement other ongoing efforts to create open system hardware designs, such as the Open Compute Project's.
One possible downside of Linux becoming an ubiquitous infrastructure element is it becoming as institutionalized as the commercial, closed source Unixes it has displaced. But Zemlin thinks Linux's very mutability works in its favor here: "If you would have asked Linus Torvalds or other members of the community a decade ago if Linux would power more mobile phones than any other platform, they certainly wouldn't have expected that. We'd rather just watch where it goes and not try to forecast since we most certainly will be wrong."
Another important future direction for some is, as mentioned above, "go[ing] mobile in a bigger way independently of Google," as Baker puts it. Projects like Mozilla's Firefox OS for phones are one incarnation of this, although it's unclear how much of a dent such a thing will make in Google's existing, and colossal, market share for Android.
Lastly, and most crucially, there's the question of who will be responsible for ushering Linux into its own future. While Linux can be forked and its development undertaken by others, history's shown that having a single core development team for Linux -- and equally consistent core teams for projects based on it -- is best.
That puts all the more burden on the core team to keep Linux moving forward in ways that complement its existing and future use cases, and not to protect it -- perhaps futilely -- from becoming something it might well be in its best interests to transform into.