I’ve been continuing to study. The Linux class is going all right; I’m halfway through and just took my midterm exam this past Thursday (which was basically, “do you know how to use basic command line commands? yes? kthxbye, this class is only 30 minutes long”). Most of what we’ve gone over so far was stuff I already knew how to do… but I think we’re past that now. It surprised me how much I’d already picked up from messing around with an OS I wasn’t even using as my primary.
The teacher thought I’d been using Linux quite a bit longer than I had. Actually, whenever I clarify that I’ve only played with the system, she kind of deflates a little. At least, that’s how my brain parses it. This teacher’s really hard to read. I wouldn’t want to play poker against her. She knows her stuff and she’s pretty friendly–definitely NOT a bureaucrat–but she seems jaded, and often worn out from her day job as the school’s only Linux tech by the time we see her. Oh, and she has a real thing for popcorn. Not related, but I thought it was funny.
I’ve been studying on my own, too. I’m on my second read-through of ESR’s Cathedral and the Bazaar. I agree with the points in his paper (unless I’ve missed something). The paper is a pretty thorough study of how open-source works and its advantages over closed-source, corporate development. It also goes in depth as to ESR’s proud parenthood of his beloved baby program, Fetchmail. 😛 He provided his experience with Fetchmail as an example, but if a guy could be more affectionate and nostalgic towards a set of instructions to be given to a hunk of organized sand which displays lights in patterns in a box, I don’t know how.
I enjoyed CatB. I found myself finishing ESR’s sentences once or twice before turning the page on my Kindle. I made a few observations that I think he missed, too, and once I’m done with this second read-through (in which I’m taking notes on his main points and what I think can be extrapolated and applied to modern programming–a lot has changed in the, what, 15 years since he updated the version of the paper I have), I’ll try to remember to post them here. I also think that if closed-source companies are going to keep writing and selling software, they should at least take a page out of the open book and use open-source tactics to help develop their software. It would mean that closed companies might produce better software, and that’d give the help-desk people a bit of a break–plus the benefit of getting closed companies used to the way open-source culture works and maybe making it easier for them to leave closed-source behind in the future.
Perhaps I’ll end up writing my own paper suggesting how they should do this. I don’t think I know enough about software companies’ internal structure to do so now, however. But I will later, because I intend them to hire me one day. (Not Microsoft, though.)
I’ve also been reading–trying to read, anyway–the Halloween Documents. (link)
These are much less pleasant to peruse, but I want to know what they’re about. It’s really hard to follow the logic. I’ve gotten 2/3 the way through the first paper and I’m starting to think maybe that’s because there isn’t much logic to be found. Is this how they write code, too?! CatB mentions a quote from somewhere that basically says that every time a group develops a system (like a piece of software), its structure mirrors that of the way the group communicates within itself. So if this is how a Microserf writes a paper–with disjointed logic and poor organization–is that what Microsoft’s code looks like?
Speaking of that quote, I remember one of my observations that got missed by ESR–probably because I’ve steeped myself in a different era in programming. Actually, it’s my favorite of the things I noticed. Consider:
Any structure a group writes will mimic the way the group communicates.
Brooks’s Law that adding more developers to a late project makes it later is based on the assumption that every member of the group needs to communicate with each other, and the overhead cost of that communication causes the lateness.
Open-source development models eliminate Brooks’s Law because they’re better organized; different developers need only really communicate with the lead dev, not all of each other.
Now consider procedural programming versus object-oriented programming. In particular, look at object-oriented programming and compare it with open-source structure.
In each program, there’s a main method that runs first. It calls the other methods, which do various tasks within the program depending on user input, but often the main method itself doesn’t do much. There are probably some variables in main that get passed to other methods, but main doesn’t do much heavy lifting, on the whole. Those tasks are delegated to other methods. main just organizes them and fits them together.
In open-source, the lead dev (or lead devs, up to about 3 according to ESR) have an idea, write up a basic “scaffolding” or infrastructure for their program, and then make a call out to the open-source community to come and help with their idea. Then, if the idea catches on, an extraordinary amount of delegation takes place. Other hackers do smaller pieces of the process to help, and the leads’ job is now more that of a manager than a coder–although they’re certainly not to be mistaken for the useless lumps that pass for managers in many corporations, or for the managers who don’t actually have very much to do with the code and just try to keep the bureaucrat higher-ups out of their coders’ hair. They are in fact what managers should be: competent people overseeing a project.
Anyway, where was I? Oh, yeah. The Halloween Documents.
I don’t need to bash how terrible the tactics described are, or how obtuse the writer is. It’s pretty obvious to anyone who reads the thing, especially with ESR and TN’s comments interspersed as in the link I posted earlier.
I will mention that the writing style is… obfuscated. ESR writes clearly, and explains jargon and techspeak terms alike where necessary to grok his points. But this Microsoft guy is writing out of some Micro-bureaucrat dictionary, and disjointed as his points already are, it doesn’t help in making the paper easier to understand. ESR’s paper calls back to previous points in many places, which underlines the paper’s internal consistency. Like calling a method multiple times in the same program, because you wrote it well enough to reuse it. But this other paper, this Halloween paper… it’s internally inconsistent in many different places and it’s hard to understand what the writer’s trying to say.
It also seems like it’s padded out by repeating points. Not just calling back to previous points like ESR does, but it’s as if the writer copy-pasted the first time he wrote out his points and then changed the wording and formatting, made it a bulleted list or something.
Trying to parse the thing is kind of giving me a minor headache, not to mention it’s boring to read. I’d like to get the other perspective, but it seems pretty mindless and it’s tiring to read. I’m going to leave it there for the night. Maybe there’s another alternate perspective.
I would like to know how open-source software would make a company enough money to make it a viable business path. Obviously they can provide tech support, but so can open-source forums. The thing is, open-source is fine on its own. It doesn’t need a company behind it. But companies generally like to be paid, and to be paid you have to be filling a need (or, like Microsoft, at least you have to make people think you’re filling a need).
I would like to make coding my career. But I also think that the open-source development model is so much drastically better than what could be done within a closed-source corporation, and I don’t want to produce crappy software because that would be a pain to write and a nuisance to maintain and support. I’d like to know how much of open-source culture could be adopted by a company without their losing so many rights they can’t make money. In other words, I’d like to find a way for a company to make money off of open-source, or if not, I’d like to make closed-source policies less terrible and the development structure more effective.
I have time to think about this, at least. I’m 17 years old, after all.