2017-03-24 21:20:00 hackers

The Cathedral and the Bazaar

ESR's history of hackerdom seems pretty consistent with Levy's in Hackers: Heroes of the Computer Revolution- he even references Levy's book a few times. However, ESR goes on give a little more insight to the life in Hackerdom: he talks about the Jargon File (hacker slang dictionary) and how hacking reached other universities besides MIT and Stanford. The most important new insight ESR gives is the Rise of Unix, which to me is a very central idea to being a hacker. A must-have, if you will. He talks about the many different strains and flavors and how certain distributions compared. His desciptions add another layer of depth to our knowledge of hackers, a layer we hadn't received from Levy or Graham (ugh he's the worst).

ESR compares traditional software building to building a cathedral, "carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time." Before Linux came around, he saw large or important pieces of software as tasks that could only be done in a what seems like proprietary manner. However, the idea that Linus Torvalds brought to the table, "release early and often, delegate everything you can, be open to the point of promiscuity," seemed more like a bazaar where diverse people and ideas floated around in a babbling sensation.
Personally, I think most of my experiences fall under the bazaar category. First, my work is never complete, so one could argue that I always release betas (conflicting with the idea of building a cathedral). Secondly, as soon as I was introduced to the bazaar-style approach, I quickly adopted and never went back. It has been during this time that I have written my best code and learned good coding practice, so my work before then barely even counts. However, there have been two times I have had an experience more similar to cathedral-building than bazaar-babbling: my work with IBM.

IBM, one of the proprietarization proponents of the world. My experience ranges from freaking fantastic to the ultimate black hole depths of despair (you think I'm joking... sad this is I'm not). One thing was consistent- the idea of working in a bazaar. Work happened in isolation, with small groups of dedicated workers, treating their work as a secret that could impact the life or death of a million of lives. Very different than the Linux Bazaar approach, and one of the major pushes to my Bazaar-favor.

Two Philosophies of Life

Good programmers know what to write. Great ones know what to rewrite (and reuse).

Once, I made a super cool (*cough shitty) XML parser using (Coconut)[http://coconut-lang.org/] and I was super pleased with myself. Then I found a Python library that did it better and I reluctantly threw in the towl. But why use my poor-performing code when I could use an extremely well-made library? The learning experience was awesome but that didn't mean I couldn't recognize the inefficiency of using my code over the library. I think this mentality is important: code for the sake of learning, but be able to recognize when to use someone else's better work (and of course give credit where credit is due). We live in an open-source world people.

Release early. Release often. And listen to your customers.

I have become so spoiled with a rolling release Linux distribution: I'm at the bleeding edge, I'm learning a lot (which is the type of thing I enjoy), and things just get done quicker and get better quicker. This tight feedback loop really has an affect on the product. As a consumer/user of Arch Linux, I'm able to see that from the user perspective, which is the best type of perspective going into software development.

Final Thoughts

Perhaps in the end the open-source culture will triumph not because cooperation
is morally right or software hoarding is morally wrong (assuming you believe
the latter, which neither Linus nor I do), but simply because the closed-source
world cannot win an evolutionary arms race with open-source communities that
can put orders of magnitude more skilled time into a problem.

Yes. Prime example: Apple's Swift Programming Language. In typical Apple fashion, they kept the development close-source... until the language wasn't developing as rapidly as they wished. Then they made it open-source. QED.