Quotes from Eric S. Raymond

To design for compactness and orthogonality, start from zero. Zen teaches that attachment leads to suffering; experience with software design teaches that attachment to unnoticed assumptions leads to non-orthogonality, noncompact designs, and projects that fail or become maintenance nightmares.

Web pages get bogged down in the dispute over whether the reader or author should control the appearance.

Open-source development breaks this bind, making it far easier for tester and developer to develop a shared representation grounded in the actual source code and to communicate effectively about it.

One of the many consequences of the exponential power-versus-time curve in computing, and the corresponding pace of software development, is that 50% of what one knows becomes obsolete over every 18 months.

To design the perfect anti-Unix, write an operating system that thinks it knows what you're doing better than you do. And then adds injury to insult by getting it wrong.

One of the main lessons of Zen is that we ordinarily see the world through a haze of preconceptions and fixed ideas that proceed from our desires. To achieve enlightenment, we must follow the Zen teaching not merely to let go of desire and attachment, but to experience reality exactly as it is—without the preconceptions and the fixed ideas getting in the way. This

Tools that look glossy but shatter under stress are not good long-term value. Unix

Rule of Optimization: Prototype before polishing. Get it working before you optimize it.

If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.

The organization of the software and the organization of the software team will be congruent

The case can be put less negatively: where network effects (positive network externalities) dominate, open source is likely to be the right thing.

In computer hardware, where freedom reigns for both suppliers and consumers alike on a global scale, the industry generates the fastest innovation in product and customer value the world has ever seen.

if you want the most efficient production, you must give up trying to make programmers produce. Handle their subsistence, give them their heads, and forget about deadlines.

Mixing languages is better than writing everything in one, if and only if using only that one is likely to overcomplicate the program.

Are the individual functions in your modules too large? This is not so much a matter of line count as it is of internal complexity. If you can't informally describe a function's contract with its callers in one line, the function is probably too large.9 9 Many years ago, I learned from Kernighan & Plauger's The Elements of Programming Style a useful rule. Write that one-line comment immediately after the prototype of your function. For every function, without exception.

This is quite unlikely to happen to Linux

In the beginning, there were Real Programmers.

When are programmers happy? They're happy when they're not underutilized - when they're not bored - and also when they're not overburdened with inappropriate specifications or meaningless bureaucracies. In other words, programmers are happiest when they're working efficiently. This is a general preference in creative work.

A critical factor in its success was that the X developers were willing to give the sources away for free in accordance with the hacker ethic, and able to distribute them over the Internet.

Thompson and Ritchie were among the first to realize that hardware and compiler technology had become good enough that an entire operating system could be written in C, and by 1978 the whole environment had been successfully ported to several machines of different types.

Every good work of software starts by scratching a developer's personal itch.

Anyway, in a world of cheap PCs and fast Internet links, we find pretty consistently that the only really limiting resource is skilled attention.

Python language is one example. As we noted above, it is also heavily used for mathematical and scientific papers, and will probably dominate that niche for some years yet. 18.3.3

Investors are still thinking through the consequences of reinventing the software industry as one with an explicit focus on service rather than closed intellectual property, and will be for some time to come.