Today I was treated to a talk by my colleague Jordan Anastasiade on Eclipse WTP bug fixing. In 45 minutes he went through the structure of Eclipse, showed us how WTP works, demonstrated a bug in the tool, and proceeded to fix it right down to creating the patch, explaining everything as he went. I found it a thoroughly interesting digression from my Mozilla work, seeing how another community organizes itself, and the tools it uses. Some of the CDOT profs have been doing these talks every other week at lunch about our work in different open source communities, whether it be OpenOffice.org, Mozilla, Eclipse, Fedora, etc.
As soon as Jordan's talk was over, I went to give my lecture on debugging strategies for Mozilla, demonstrating the use of VS.NET and gdb, Venkman and Firebug, DOMi, etc. It's one of my favourite talks, because coping with software on the scale of Mozilla requires a keen ability to use various tools.
As we ended and I walked back to my office, I reflected on the juxtaposition of the two talks. One of the complaints you hear leveled against Mozilla is the lack of decent development tools, or perhaps, the lack of a Mozilla tool written by Mozilla. I certainly felt this void when I began. I've never been an Eclipse developer, but as I watched Jordan move through layer after layer of perspective, view, dialogs, panels, preferences, and menus, I was witnessing the sort of thing I think these people imagine they want.
Why does one project have such an emphasis on tools, while the other, an almost cavaleir disregard for the same. It's a fascinating question. At first, it's tempting to think that this is what a corporation like IBM would do vs. a community project. There might be some truth to this--IBM is surely a lot larger than Mozilla Corporation--but that can't be the whole answer: Mozilla came out of Netscape, which was also a corporate software shop.
I won't try to speculate on the historical reasons or pass judgment, but I wonder if, as Heidegger would say, we use what is ready-to-hand without noticing it. Furthermore, the thing we build, the thing we see, the thing we recognize as deficient and in need of improvement, more features, bug fixes, this thing is present-to-hand, and we encounter it exactly because we build instead of use it. I don't think that Eclipse or Mozilla can escape this mode of being: we cannot stop to notice the hammer while hammering, or we'll hit our thumb instead of the nail.
What happens when you notice the hammer? And more, what happens when you notice that the hammer needs repair? What happens when the tool you build is the tool with which you build? What is ready-to-hand will, and must, remain invisible to us. The fact that I see your tools, that I desire your tools, means that they have ceased to be tools, that they have become my concern instead of an in-order-to: one builds browsers and the other software tools, and both swing their arm oblivious to the fact that a hammer is what actually strikes the nail.