The Proper Image for Linux

Dr. Bentson did a survey of Linux kernel developers to find out about their backgrounds. Here are the results.
Current Use

Finally, I wanted to know if the contributors were “doing Linux” in their careers. Eighty-two said their current employment was based on their computer skills. It was interesting to note that over a third reported their current employment supported or relied on their Linux development efforts. Sadly, two reported they were currently unemployed, but one of those also noted that he was “voluntarily unemployed to have time to put my life in better order.”

Perhaps one significant difference between Linux development and academic or commercial development is the duration of personal interest. In an academic setting, a student typically has one term, or at most one year, to work on any given program. When programmers leave a company, support is picked up by someone who has no sense of what has gone before. There is greater continuity in the Linux community because of the nature of submission and distribution. No matter what is happening at school or where one works day to day, contributors can keep in touch with progress on their piece of the puzzle. One person noted, “Personally, I did start my code in school, but that does not stop me from maintaining it now.”


There are some other issues which weren't addressed by my survey. Although it might not seem relevant to quality and performance, a person's interest has a great deal to do with the outcome—it leads to a distinction between “craftsmanship” and “work product”. Another person noted:

“Intent” is what I think all of these debates are about. In the commercial world there is only one true answer to “Why are you helping develop Linux?”—“To make a living.” In the Linux community I'm quite certain the answer would be more closely aligned to “For me to use.” The Linux community tends to be self-driven and self-motivated, and that is what leads to the successes and the apparent failures in our development environment.

We are not a company; we don't have any one person, or group of people, setting the direction Linux will take. That direction is set by those with the energy to actually do something.

Another motive, akin to what pushed me to first join the effort, was shared by another respondent who said, “When I wrote [my code] for the Linux kernel I was working at [my former employer]. Linux use there was extensive, and I wanted to give something back.”

Motivation leads to the final and most significant issue—one which cannot be examined by a developer survey.


In a world driven by marketing, image is the basis for purchasing decisions. Even if a good image could be established for Linux by listing credentials or tabulating years of experience, I'd be reluctant to shift to that level. I'd much rather see acceptance and popularity for Linux based on quality and performance.

Even though I hadn't asked specific questions on this topic, a few people offered comments. One note seemed to identify, however obliquely, what may be the key to Linux's success.

In general, my experience is that most software I have seen which was developed by students is not of the professional quality I would like to see. On the other hand, much of the commercial software I have seen, which was developed by professional software development companies, is also not of the professional quality I would like to see. The difference is most people do not get to see the internals of commercial software.

Developing on this theme, another wrote:

The reason Linux is stable and usable is not because of its student programmers [or lack thereof]. It is because of the overwhelming feedback that alpha and beta testers provide. When you read the Linux kernel, you will find many parts are poorly structured, poorly written and poorly documented. However, people dared to test it and report their problems; Linus and friends respected the error reports and went ahead to fix them. That is why it works so well.

In addition, psychology sometimes causes weird effects. If a user discovers a bug in his system, reports the bug and sees it fixed eventually, that user is happy because he was treated with respect. Most likely, he is even happier than he would be in the bug-free case.

We not only need to bring the CREDITS file into an accurate state, but we also need to acknowledge the thousands who have contributed to Linux by using it and sharing their discoveries—good or bad—with others.

Peter H. Salus reports the UNIX philosophy in A Quarter Century of UNIX as:

  • Write programs to work together.

  • Write programs that handle text streams, because that is a universal interface.

I'd like to close by adding another entry, suggested by UNIX and dominant in Linux:

  • Write programs you enjoy.


Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
On Demand
Moderated by Linux Journal Contributor Mike Diehl

Sign up and watch now

Sponsored by Skybot