Is the Linux community going to become more, or less, dependent on the skills of Linus Torvalds? I think it will be
as dependent. It's hard to imagine it being more dependent. It's also not really clear that it needs to be less dependent. What Linus does is maintain the ever-unpopular position of rejecting stuff that doesn't belong in the kernel (the core of an operating system). The skills the Linux community will ultimately depend on are more his ability to reject than his ability to write any new code.
Will there come a point when the code becomes so unmanageable that it prevents the community from making major improvements without breaking too many other things?
A year ago, when Linux was streaking upwards, when it was just beginning to have the varsity-level characteristics of the proprietary Unix world, the question people asked me was, "How do you know you'll be able to stay on this track, or are you going to plateau the same way the rest of the Unix kernels did?" At that time, I did not have an answer to that question. I now do.
The key discriminating function of the main Linux maintainers--which include Linus Torvalds--is their absolute no-compromise position on clean interfaces and forcing people who want to go two steps forward to not go one step back. What this means is, in many kernel mailing-list discussions I've seen over the last 12 months, when somebody proposes a solution that solves some problems but brings with it other problems, generally that solution is rejected until the other problems are addressed.
A great example of this is two years ago when a number of groups approached Linus, each trying to be the approved security mechanism for Linux. The NSA (National Security Administration) was showing their solution, HP (Hewlett-Packard) was showing their solution and Immunix/Wirex was showing theirs--and he told them all, "The fact that each of you is trying to get me to adopt your approach is proof that none of these approaches is correct. The only possible correct approach is one single approach that supports each of the different things you're trying to do. Come back when you've defined a set of interfaces that supports each of your systems, and I'll support that."
Two years later, somebody comes back with the LSM patches, the Linux security module, which in fact supports of each of these different ways. By preserving the integrity of interfaces and, by not picking a solution that excludes other solutions, Linux does retain a scalable development model. I could tell the same story about the Linux kernel scheduler; I could tell the same story about the native Posix thread library, which as you may know supplanted NGPT (next-generation Posix threading). In recognition of Linux not supporting large threading models, IBM developed something called NGPT, which somewhat solved that problem but also created other problems. For two years, the Linux kernel guys rejected those patches, much to the frustration of the people at IBM, who all knew that this was really necessary to run a Java-rich environment. What NPTL has done is dramatically solved the problem in a way that results in no compromise for anyone. It not only speeds up programs that have large threading requirements, it speeds up everything.
How does the open-source business model look when you compare 1989 to the present and future?
In 1989, it was 100 percent vision. Today, it's getting close to 100 percent reality. When we started in 1989, our sales pitch was much more evangelical. Nobody in the enterprise market buys until everybody else does. In 1989, I can tell you, nobody was buying. Today the reports from Wall Street, from manufacturing companies, from various governments around the world...all point to the fact that the open-source model is working.
Then is the battle over open source won?
I wouldn't say that. We have managed to secure our spot in the Olympics.
Say it's three years from now. Are you holding the bronze, silver or the gold?
We're trying to make a determination about whether the officials are going to cite other companies for illegal use of steroids. On a level playing field, there's nothing to keep us from getting gold. I think our biggest concern is going to be whether or not the competition lets the games be fair or not. From a technology perspective, I'm very comfortable where we are. We were probably the fastest company to get to the level we got on ECperf, TPC-C, TPC-R and other (performance) benchmarks.
When you look at the rate we have climbed from the amateur hour to the top spot in our category, I think we have shown that the technology and our business can not only reach the levels of competition that exist today, but set some new benchmarks.
What political challenges will open-source face in copyright law or digital rights management or intellectual property issues?
Open source is just one of many categories that brings into focus the public versus private debate. Today, libraries are fighting for rights to provide the same access to information being released, only in a digital media form compared with information released in traditional forms. Fifty years ago, certain court cases established that yes, by golly, a library has the right to purchase a book and make it available for lending because of its public service.
But there were certainly points in time when booksellers didn't want libraries to exist, because they wanted to sell books to every person in the U.S. A doctrine was established that there was a balance between public and private interests, and that libraries served the public interest. Of course, they also respected the private interests by acquiring the materials that they lend in a legal fashion.
With new digital rights management and the DMCA (Digital Millennium Copyright Act), these companies are using technology to prevent libraries from fulfilling a role they have always fulfilled using more traditional technologies. The question of open-source and IP (intellectual property) and digital rights management is in no way limited to Linux or Red Hat or open source.
What's the biggest problem in Linux that will be fixed in the next three years?
There had been some outstanding technical challenges around threading (in which a program has several programming tasks, or threads, running simultaneously), around SMP (the ability for Linux to run on mammoth systems with numerous processors and lots of memory), around kernel scheduling (how the operating system juggles between different tasks), around network stack performance (how fast network traffic is processed).
Almost all of those problems have been solved so well it's almost mind-boggling.
In three years, will Linux run well on 32-processor servers?
I think it'll run well in less time than that.
How about 64-processor servers?
If (Oracle CEO) Larry Ellison's right about 9i RAC (the Oracle 9i Database with Real Application Clusters)--and some benchmarks suggest that if he's not right, he's not far wrong--then people are going to have the ability to deploy 64-way Oracle databases by buying two 32-way systems or by buying 32 two-way systems.
Do you think Linux will ever displace Microsoft on the desktop?
That's not a technology question. The big bugaboo there is related to the (antitrust) testimony I gave in February.
Which do you think will prevail, Berkeley Software Distribution (BSD)-style licenses or General Public Licenses (GPL)-style?
The Berkeley license permits privatization of technology, which means it permits a company to exclude others from their own development project; whereas the GPL prevents people from being excluded from a development project. Generally important software will be under GPL, and specifically important software will wind up under BSD.
Which will be more relatively popular?
I think GPL will remain the most popular. I think it is going to be the generally important software that continues to be covered by it.
What fraction of open-source programmers are hobbyists or working in their spare time on a self-appointed basis, and what fraction are on some company's payroll being paid to work on specific projects?
One, almost all of the people who are committing code to open source--we're excluding people who just provide commentary on Slashdot but including people who get their name into source-code repositories--virtually all those people are employed as professional programmers. Two, a large percentage of those are sanctioned in one way or another on working on open-source software, either because it is directly or indirectly relevant to the mission they're being employed for.
What part will you play in the future development of an open platform?
I've talked to a lot of CIOs still suffering from the hangover of the so-called Unix open-systems wars. The fact is, the fragmentation of Unix was a disaster both for Unix as a platform and for customers who purchased a lot of expensive proprietary systems. One of (our) roles is keeping the platform truly open, keeping the integrity of what it means to be an open standard really solid.
Politics aside, what challenges will pragmatists face in the next three years?
The industry right now is clearly out of balance. Many people would argue now that there is an oversupply of technology and an undersupply of quality. There's undersupply of competition, there's oversupply of incompatibility.
I think there are still a lot of companies that are going to get shaken or wrung out of the industry because it's a very challenging economic time. The pragmatic challenge, for (computing equipment) suppliers and customers, is going to be aligning their computing resources and technologies around a new world order. That new world order is going to have more open standards in the future than it does today.
Is it fair to say you're the first person to start a company with open-source software at its core?
Absolutely. In 1989. It was the first and for a while, the only company that believed it was possible to commercialize GPL and later open-source software.
This was two years before Linux actually started?
That's correct. At that time, we had the wisdom that to be a successful company, one had to have focus. Even though, at the time, there was a lot of software that could be commercialized under open-source licenses, such as the MIT X Windows system or many of the Berkeley user-level command utilities which make Unix such a powerful platform. There were tons and tons of software available at the time, but what we believed about the key lever and the key opportunity was based on the development tools. We executed that very successfully.
We grew our revenues at the classic 100 percent a year, for the first three or four years. We edged up our profitability from marginal to reasonable over that same period of time. The company became successful enough that we secured a multimillion-dollar investment from the venture capital community in January 1997.
What is Red Hat's role going to be in the future?
Our role today and going forward is creating a true open platform. I've talked to a lot of CIOs still suffering from the hangover from the so-called Unix open-systems wars. The fact is, the fragmentation of Unix was a disaster both for Unix as a platform and for customers who purchased a lot of expensive proprietary systems. One of the roles I think we've got going is keeping the platform truly open, keeping the integrity of what it means to be an open standard really solid. We believe with free and open competition, the truly best and deserving alternatives will win in the marketplace.
So your goal is to create standards or keep to standards?
It's a mix of both. There are a lot of technologies today that need to have open-source implementations and need to have open-standard definitions. There's a battle right now at the World Wide Web Consortium. I think a strong definition of open standards has won round one, but I don't think the opposition is going to give up the fight that easily.
Are you referring to battles over whether standards should be covered under reasonable and nondiscriminatory (RAND) agreements, under which companies may still charge for their intellectual property?
Exactly. I think there are a lot of companies who want to continue to permeate their proprietary technologies into what people are demanding, which is open standards. I think CIOs are now smart enough to realize you can't really have it both ways. If there's s a single control point, that single control point is going to get abused. What Red Hat is building is a platform where there can always be multiple competing solutions. Our role as a business on that level playing field is to be the best business we can be.
So should companies not be compensated for intellectual property they've developed?
Companies are always free to develop intellectual property in whatever way they see fit. But I don't think that companies should use the development of their own IP as a lever against people who want to use systems they've purchased.
The story of the World Wide Web is a story often told. It is important to remember that (Web pioneer) Tim Berners-Lee had to fight 12 board members at CERN to get his software to be released. Hyperlinked, networked, graphical systems--all the systems we think of as the World Wide Web--had been developed multiple times in the past, but they never achieved critical mass because the attempts to make them proprietary and attempts to exploit exclusive technologies were never effective in building true critical mass. Even Microsoft has seen some success in terms of making XML a technology-neutral, vendor-neutral standard, and boom--it becomes the lingua franca of Web services.
There's a lot of criticism that the open-source movement has been good at reproducing an existing environment--cloning Unix, cloning CDE (Common Desktop Environment), reverse-engineering Microsoft's SMB (Server Message Block) protocols. What are the new areas where the open-source community will lead the rest of the industry?
We're definitely on the cutting edge with respect to security. The fact is, companies aren't spending as much on security as they know they should. My supposition is that the reason people are spending so little on security is because the existing proprietary platforms offer such poor security alternatives, meaning they're either not very secure or not easy to implement, or not easy to maintain, or not flexible or not compatible. The community that has had experience in making technology ubiquitous through open models is the community that's going to find and deliver security solutions that warrant responsible spending by IT organizations.
So (Sun Microsystems') Solaris is less secure than Linux?
People have reported on numerous occasions the cost differential between a proprietary system and a Linux-based system. People don't want to spend money on things that are considered too expensive. Even if Sun does have adequate security in one dimension, the overall commercial offering is just not very attractive compared to what the IT departments are demanding.
How will the open-source community push security forward?
There's a lot of work going on surrounding a development called Security-enhanced Linux. This has been adopted by the community. People are using Debian (a free operating system that uses the Linux kernel) as a base, then feeding that through and into and back from the community.
Where else will the open-source community be coming up with new ideas?
Manageability. I think there was little incentive for the open-source community to worry about building large-scale management platforms when Linux was only running on individual machines clandestinely. Now that people are deploying Linux by the thousands in their organizations, there is an incentive to work on manageability, and I think the Linux approach is going to be very different from the old approach.
How?
In the old approach, the manageability tools had to necessarily treat the operating system as a hostile platform. You've got all these proprietary Unix platforms evolving independently. Plus, each of these different operating systems was trying to build its own independent manageability framework for that one operating system. Because of the high degree of fragmentation of Unix, this meant a lot of resources were being spent very duplicatively, the result being that multiplatform, proprietary management platforms were very expensive.
Because of the open-source model, a lot of people can collaborate on a common way of building things. Because the source code for Linux is completely in the open, it is not necessary to treat the operating system as a complete black box. I think we can have cooperative manageability as opposed to adversarial manageability.
Back to Vision Series
intro
