More on this book
Community
Kindle Notes & Highlights
“The Unix philosophy is really very easy,” Salus says, “and consists of maybe two or three notions. The first one, which is perhaps the most innovative thing that Thompson ever thought of, is that everything is a file. Second is the notion that when you build something, no matter whether it’s an editor or whether it’s a way of attaching one file to another file, you write things that are for a single purpose but do that purpose well.”
This approach of releasing code and encouraging feedback and modifications from users, although not new–it had formed an implicit part of the entire Unix culture for years–became central to the rapid improvement of free software over the next fifteen years. Its adoption in an extreme form for the development of Linux was one of the key factors in its rapid growth and robustness.
He has no car: “I live in a city where you don’t need to have a car.” He rents a room: “I don’t want to own a house, I don’t want to spend a lot of money. If you spend a lot of money then you’re the slave of having to make money. The money then jerks you around, controls your life.”
“If you don’t have freedom as a principle, you can never see a reason not to make an exception. There are constantly going to be times when for one reason or another there’s some practical convenience in making an exception.”
The Linux movement did not and still does not have a formal hierarchy whereby important tasks like these can be handed out, an apparent weakness that has proved a strength. A kind of self-selection takes place instead: Anyone who cares enough about developing a particular program is welcome to try. Because those most interested in an area are often the most skillful, they produce high-quality code. If they succeed, their work is taken up. Even if they fail, someone else can build on their work or simply start again.
The arrival of cheap CD-ROM technology in the early 1990s probably played as crucial a role in the commercialization of GNU/Linux distributions as the arrival of cheaper PCs using the 80386 did in the original genesis of Linux itself. Had this new medium not been available at the right price, there would not have been the sudden flowering of companies selling low-cost CD-ROM-based distributions.
Once again, what might be called the Linux method is evident: Rather than trying to develop software on the best possible environment—a fast processor, lots of memory, no strange peripherals—you use an underpowered machine with lots of extras to winkle out unusual bugs.
Allman says, and adds with characteristic modesty, “you know, there’s this saying that all innovation is done by lazy people; and I’m fundamentally a lazy person.
“Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging,” he writes. “Release early. Release often. And listen to your customers.” And last: “given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.”
There are precedents for gifted individuals who conceive and work on huge projects, often with little hope not only of recompense but of recognition. In other spheres, these people are called artists, and much of the history of art is the story of those who create masterworks out of an inner necessity to do so, over and above what they may have been paid to produce.
Just as the best source code always implies the existence of a usable binary, so there seems to be a sense among hackers that the best software—the most beautiful as Knuth and others would say—implies that it serves its users as much as possible.
” as Hecker explains. “If you’re going to be inviting other people to be involved in your development process, then you’re going to have to expect that they may have opinions of their own which may not in all cases agree with your opinions.”
IBM is like a big elephant,” he says. “Very, very difficult to move an inch, but if you point the elephant toward the right direction and get it moving, it’s also very difficult to stop it. So we kind of joke [in IBM that] figuring what’s the right thing to do is less than 10 percent of the effort; 90 percent of the effort is to figure out how to leverage the bureaucracy.”
Young also realized that the real business model for GNU/Linux and open source was selling services, not the product.
Sifry says they decided the solution was to “build a knowledge base that’s Web-based [where] we feed everything that we do in the business into that. Because the last thing you ever want to do is you want to answer the same question twice.”
This analysis implies, of course, that the key asset for any open source company, even more perhaps than for conventional companies, is the people it employs. Because the “product” is open source, and freely available, businesses must necessarily be based around a different kind of scarcity: the skills of the people who write and service that software.
“One of the things you’re doing with benchmarking is you’re trying to work out which subsystem on the server is the bottleneck,”
Compromise is not an option when it involves fundamental issues of principle,
