More on this book
Community
Kindle Notes & Highlights
ITS stood for “Incompatible Time-sharing System” which gives one a pretty good fix on the MIT hackers’ attitude. They wanted it their way.
The PDP-10 hackers tended to consider the Unix crowd a bunch of upstarts, using tools that looked ridiculously primitive when set against the baroque, lovely complexities of LISP and ITS. “Stone knives and bearskins!” they muttered.
Until the Linux development, everyone believed that any software as complex as an operating system had to be developed in a carefully coordinated way by a relatively small, tightly-knit group of people.
The mainstreaming of the Internet even brought the hacker culture the beginnings of respectability and political clout. In 1994 and 1995 hacker activism scuppered the Clipper proposal which would have put strong encryption under government control. In 1996 hackers mobilized a broad coalition to defeat the misnamed “Communications Decency Act” and prevent censorship of the Internet.
Linus Torvalds’s style of development — release early and often, delegate everything you can, be open to the point of promiscuity — came as a surprise.
Every good work of software starts by scratching a developer’s personal itch.
Good programmers know what to write. Great ones know what to rewrite (and reuse).
“Plan to throw one away; you will, anyhow.”
Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
Rather, Linus seems to me to be a genius of engineering and implementation, with a sixth sense for avoiding bugs and development dead-ends and a true knack for finding the minimum-effort path from point A to point B.
Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
When writing gateway software of any kind, take pains to disturb the data stream as little as possible — and never throw away information unless the recipient forces you to!
Nowadays it’s more important for a language to be convenient for humans than to be cheap for the computer.
A security system is only as secure as its secret. Beware of pseudo-secrets.
A bazaar project coordinator or leader must have good people and communications skills.
In order to build a development community, you need to attract people, interest them in what you’re doing, and keep them happy about the amount of work they’re doing.
To solve an interesting problem, start by finding a problem that is interesting to you.
In his discussion of “egoless programming”, Weinberg observed that in shops where developers are not territorial about their code, and encourage other people to look for bugs and potential improvements in it, improvement happens dramatically faster than elsewhere.
Both the fetchmail and Linux kernel projects show that by properly rewarding the egos of many other hackers, a strong developer/coordinator can use the Internet to capture the benefits of having lots of co-developers without having a project collapse into a chaotic mess.
Human beings generally take pleasure in a task when it falls in a sort of optimal-challenge zone; not so easy as to be boring, not too hard to achieve.
A happy programmer is one who is neither underutilized nor weighed down with ill-formulated goals and stressful process friction.
It may well turn out that one of the most important effects of open source’s success will be to teach us that play is the most economically efficient mode of creative work.
In gift cultures, social status is determined not by what you control but by what you give away.
“You may not work to get reputation, but the reputation is a real payment with consequences if you do the job well.”
Furthermore, past bugs are not automatically held against a developer; the fact that a bug has been fixed is generally considered more important than the fact that one used to be there.
Continued devotion to hard, boring work (like debugging, or writing documentation) is more praiseworthy than cherrypicking the fun and easy hacks.
What they know is this: the price a consumer will pay is effectively capped by the expected future value of vendor service (where “service” is here construed broadly to include enhancements, upgrades, and follow-on projects).
In other words, software is largely a service industry operating under the persistent but unfounded delusion that it is a manufacturing industry.
Indeed, widespread use of open-source software tends to increase its value, as users fold in their own fixes and features (code patches).
Part of the answer lies in the fact that people don’t merely need solutions, they need solutions on time.
in a properly-written accounting package, business knowledge should not be expressed in code at all but rather in a schema or specification language implemented by the accounting engine (for a closely parallel case, consider the way that database schemas separate business knowledge from the mechanics of the database engine).
Security is an aspect of reliability; only algorithms and implementations that have been thoroughly peer-reviewed can possibly be trusted as secure.
Going this path, you can get the exact features and customizability you want, though you’ll pay for it in development time. Your firm may also find it has a problem when you retire or leave.
Custom or in-house developement
When the rent from secret bits is higher than the return from open source, it makes economic sense to be closed-source. When the return from open source is higher than the rent from secret bits, it makes sense to go open source.
A consumer’s rational desire to avoid being locked into a monopoly supplier will increase its interest in open source (and, hence, the competitive-market value for suppliers of going open) as the software becomes more critical to that consumer.
In a future that includes competition from open source, we can expect that the eventual destiny of any software technology will be to either die or become part of the open infrastructure itself.
If you’re really ahead of the game, plagiarism is a trap you want your competitors to fall into!
The real conceptual breakthrough, though, was admitting to ourselves that what we needed to mount was in effect a marketing campaign — and that it would require marketing techniques (spin, image-building, and rebranding) to make it work.
Hackers solve problems and build things, and they believe in freedom and voluntary mutual help.
So, if you want to be a hacker, repeat the following things until you believe them: The world is full of fascinating problems waiting to be solved.
(You also have to develop a kind of faith in your own learning capacity — a belief that even though you may not know all of what you need to solve a problem, if you tackle just a piece of it and learn from that, you’ll learn enough to solve the next piece — and so on, until you’re done.)
Creative brains are a valuable, limited resource. They shouldn’t be wasted on re-inventing the wheel when there are so many fascinating new problems waiting out there.
So to behave like a hacker, you have to develop an instinctive hostility to censorship, secrecy, and the use of force or deception to compel responsible adults. And you have to be willing to act on that belief.
Hackers won’t let posers waste their time, but they worship competence — especially competence at hacking, but competence at anything is good.
The hacker attitude is vital, but skills are even more vital.
Being a social outcast helps you stay concentrated on the really important things, like thinking and hacking.
But there is a more fundamental error in the implicit assumption that the cathedral model (or the bazaar model, or any other kind of management structure) can somehow make innovation happen reliably.
Insight comes from individuals.
This is basically destroying brainstorming
Therefore the root problem of innovation (in software, or anywhere else) is indeed how not to squash it — but, even more fundamentally, it is how to grow lots of people who can have insights in the first place.
