Who created Linux? Sure, Linus
Torvalds has been there from
the start, hacking the kernel
and nurturing its growth. And
for the most part, Linux has been built by developers just like him -- individual contributors writing software for their own, individual reasons. But today companies, as well as individual developers, are looking for ways to contribute to Linux. Big companies. Firms like IBM, SGI, and Intel all want to bring their big company technology and big company resources to the Linux community.
Who created Linux? Sure, Linus
Torvalds has been there from
the start, hacking the kernel
and nurturing its growth. And
for the most part, Linux has been built by developers just like him — individual contributors writing software for their own, individual reasons. But today companies, as well as individual developers, are looking for ways to contribute to Linux. Big companies. Firms like IBM, SGI, and Intel all want to bring their big company technology and big company resources to the Linux community.
This is a Good Thing; Linux was built on an open model that thrives on increased contributions. We don’t really care where this software comes from; we care that the technology is sound, and that it’s Free. In fact, creating some of the software that the big players bring to Linux would require resources far beyond the reach of your average individual developer.
Now alongside these big companies and individual developers there is a new class of company that is having a major impact on Linux development: the Linux company. These are the companies that have built their business around Linux. My company, VA Linux Systems, as well as others like SuSE, and Red Hat Software all employ developers who contribute heavily to Linux and other Open Source Software.
But companies are complicated animals, and big companies are not used to working on OpenSource projects. As they become more involved in Linux development, culture clashes are bound to evolve. For example, SGI’s IRIX scales reasonably well across 4,000 processor machines. How does an SGI go about contributing that scalability technology to Linux? Where does it begin?
The culture clash I’m talking about has its roots in the contrast between Open Source development and what I call the “big company” software development model.
Traditional software development involves things like project managers, schedules, feature lists, contracts, milestones, and deliverables. The process usually requires a product marketing group that defines requirements. They, in turn, are fed to an engineering group where a team implements the product. This methodology is driven by the idea that the company is creating a product to satisfy market demand. Open Source development is driven by different factors. There are many, many reasons why Open Source Software gets written, but what’s important is how the role of the engineer differs in the two models.
In the corporate world, software is produced by companies, not engineers. The software they produce is not necessarily identical to what the engineer would like to create. It is often designed to meet marketing rather than technical needs. Now, responding to market demand can be a good thing, but this kind of design often leads to technical compromises. Who’s the lead programmer on Windows 98? Can you think of the names of any key commercial software developers? It’s not that easily done. Engineers in the corporate world are more like interchangeable cogs — resources that get allocated or de-allocated from project to project.
But in the Open Source world, the engineer is king. Projects belong to engineers, not to the company. Commercial interests are secondary to the individual’s technical integrity. For example, a company might want to make a piece of software look or feel like a Windows application for business reasons; they want to sell a clone-like product to Windows users. The engineer, however, will want to make a better interface, something that’s a generation ahead of Windows. That individual competitive drive for technical excellence is what propels Open Source Software ahead of proprietary code.
This fundamental culture clash of big company marketing needs versus little developer technical purity will run to the core of how big companies work with Linux.
Paths to Linux
There are four major ways that software gets added to Linux. The first is the traditional model. This is the paradigm we all know and love, where individuals hack late into the night to create software on their own. Most of Linux was developed through this traditional Open Source development model. Individuals or small groups of developers implement features with little guidance or control from any company. There’s no contract and there are no deliverables. It’s the individual who’s interested in the result; companies might support the programmer with documentation, technical support or some other modest resource.
Big Company/Little Developer
In this model the company directly supports the individual, and often there’s a contract. The goal of the development work is prescribed by the company. For example, a company may solicit an individual with relevant experience to write a device driver for one of its products.
This model can succeed if the working relationship between the big company and the individual is healthy, and if the company’s expectations are well-defined. Developers who excel at this kind of work usually have a history of consulting, and they’ve learned the importance of carefully defining the needs of the client.
A number of issues can make this approach difficult. First, it’s easy for the individual to be overwhelmed by the large company. Large companies may look for things like development schedules and status reports — accounting busy-work that is anathema to the productive programmer. Second, the individual developer may need to accept some degree of contractual liability. Finally, there is the question of long-term support. Unless you’re writing a simple patch, software that is not maintained becomes useless. If the individual developer isn’t going to support the new code once the contract is up, the code will rot and die.
Big Company/Linux Company
This is a new model that has appeared only recently with the rise of a new class of company, the Linux company. Linux companies (like VA, for example) generally work closely with the Linux community and individual developers. They understand the Open Source model. And they bring that understanding, along with Linux development expertise, to big companies.
The Linux company can be a buffer to the big company, assuming contractual liability and converting the Open Source development model into the schedules, milestones, and feature lists that big companies expect. This protects the developer from these obligations and shields the big company from liability as well. Big companies worry about opening up their intellectual property by contributing to Open Source projects. By using a third party, they can create a well-defined firewall between their internal operations and the outside world.
The Big Company as Big Contributor
Finally, large vendors may choose to contribute directly to Linux. As companies gain more experience with the Open Source model, this will happen more frequently. It’s something that we need to encourage for the Open Source model to continue to grow.
But big companies still have a lot of issues with the Open Source model. First, it directly exposes the company’s developers to the outside world. Corporate lawyers hate that. Big companies tend to have a lot of money, and they can make attractive targets for lawsuits. Even if an employee contributes Open Source code developed outside the company on the employee’s own time, the company could become a lawsuit target if that code violates
a patent. Further, rightly or wrongly, companies have information that they consider secret. They worry that exposing internal employees directly to the outside world also exposes their intellectual property.
Finally, big companies tend to work on release and development schedules that work against the acceptance of their code into Open Source projects; in Eric Raymond terms, they work
in Cathedral development mode. The Cathedral model often makes it hard to contribute to Open Source projects, because the leaps in development are often too large for developers to digest.This makes enhancements or new projects likely to get rejected for the simple reason that they are too big and too radical.
Contributing to an Open Source project means working with small incremental changes in a framework where the existing developers can see the direction the process is taking. The key here is that the process has to be open; not just the results.
Navigating the Bazaar
If you work for a big company, there are some things you can do to make life easier as your firm moves into the Open Source world. First, understand the Bazaar development model described by Eric Raymond (http://www.thyrsus.com/~esr). Understand how the model produces software, and the goals and motivation of the developers. One of the most enlightening things you can learn is that money is not the ultimate motivating factor here, as it is in the commercial world.
As you enter the Open Source world, partner when you don’t understand, and experiment to learn more. Your organization needs to learn the right ways to interact with the Open Source community, and running a few experiments lets you do that. Pick a few projects where you can afford to make mistakes and learn from them. Try different models; contribute some code directly, work with individuals, and work with Linux companies. Learn what works best for your culture. Don’t demand that your initial attempts become runaway successes. There will be hurdles and there will be disappointments. Remember that the willingness to give up control is a basic principle of Open Source development. Culturally this is a shock to big companies. You have to be willing to give up control. Understand the Free Software Foundation’s GNU General Public License (GPL), and make it your first choice in developing Linux software.
Entering the Cathedral
If you’re a small developer looking to work with a big company, remember that most of the latter are clueless. Not all, mind you, but it’s better to assume that they are. A pleasant surprise beats crushing disillusionment, every time. When they do need a clue, apply the clue-stick gently. Gentle nudging is surprisingly effective. Reserve Slashdot-style flame-wars for only the incorrigibly clueless. Linux is successful enough that most companies want to do the right thing, and are usually happy to have someone explain this to them.
Understand the company’s point of view. Big companies have paying customers and obligations to those customers that they must consider.
Rightly or wrongly, big companies also have intellectual property concerns. Understand them, even if you disagree with them. Remember that economic arguments carry more weight than social arguments in the corporate world. If intellectual property is the issue, argue the economic benefits of Open Source to the company.
As Linux companies become bigger and bigger, and the temptation of money from big companies becomes greater, they need to remember their roots in the Linux community. Remember, no one company will ever be in charge. The developer community is in charge. Even if key developers work for your company, respect their intellectual integrity. Don’t let money dictate technical choices. Let the technology speak for itself.
Stay true to the Open Source model.The temptation to develop proprietary software grows as the company is expected to make money. Stick to Open Source licenses and resist the temptation to use other licenses. It’s easy to begin down a slippery slope toward licenses that are not open. Stick to the GPL and you won’t have that problem.
The mix of Linux contributors is changing. These changes bring more resources and new technology to Linux, but they bring with them the danger of disappointments as the Open Source culture clashes with the corporate culture. All of us, from big companies to little developers want Linux to succeed. By understanding each other’s needs and working together we’ll guarantee that this will happen.
Larry Augustin is President and Founder of VA Linux Systems Inc., the first Linux systems vendor. He can be reached at email@example.com.