"And yet a great many of our institutions are set up to discourage, distract, destroy and derail the making of anything."<p>This may not be obvious to everyone writing software. Or maybe authors today just do not care. They are too busy chasing users.<p>As for the later some who would call themselves "hackers", I wonder: Did the original "hackers" from whence the term was taken have such ambivalence and accept what was made for them (including "platforms") fully knowing that it meant lock-in?<p>Thwarting "hackers" from making things for themselves may not always be obvious today because in fact some of these "institutions" are set up by organizations who desperately <i>need</i> developer contributions.<p>As long as they can take the contributions and use them to generate revenue or mindshare <i>for the organization</i>, they appear to be <i>encouraging</i> people to make things... but only if authors agree to jump through hoop after hoop.<p>"Instituition": Want access to our pool of end users? Jump!<p>Today's so-called "hacker": How high?<p>But what if the "hacker" <i>does not plan to share</i> his program with end users? What if he is writing it only for himself?<p>What is the purpose of making such an author jump through <i>any</i> hoops? How does that serve the author in any way?
> Indeed, several point the fingers at closed-source software as the problem which I think is an incorrect, but not entirely unreasonable view.<p>I have to disagree with you there. Being able to create a <i>fix</i> rather than a <i>workaround</i> is <i>very</i> important to us hackers. Proprietary software is a thick wall we often beat our heads against. Since all software is written by hackers, we should promote a culture of making that software <i>free</i>.<p>Apart from that detail (wherever repeated), this is a fantastic article! There is definitely a trend from hacking to thinking, and there are several ways we can get that trend flowing the other way.<p>It course, thinking is the most important aspect of hacking, so we should find ways to minimize those other aspects. For example, creating a parser/editor to style code so we don't waste time nitpicking.
The note on the commonality of patch authors making changes after getting an r+ at Mozilla is a little misunderstood here. It's very common at Mozilla to grant "r+ with nits", which is to say "yes land this code, but make these changes first". It's generally not acceptable for patch authors to make arbitrary changes after review, since that should incur another review!
1) Who the hell is "Hacker Monthly"?<p>2) I wouldn't call Dr Dobbs a <i>hacker rag</i>. That'd be 2600, or PoC||GTFO, or Phrack. Dr Dobbs is a trade journal.