9 Nov 2000 »
work
Hint to business types negotiating contracts to get someone else to do your IT work: security is important. Get advice, talk to lawyer types, include it in the contract or you will get attacked, and you will lose money.
hackery
Submitted a late entry for linux.conf.au. I’ll see if I’m accepted soon. I have some ideas I want to present to the crowd. They won’t like it much, and it should be controversial. Basically, it goes like this:
Cathedral and the bazaar is as an apt a description of the OSS process as any I’ve read. It’s also fairly cogent (particularly for esr 🙂 and is backed up by many of the smaller projects I’ve been involved with.
C&B also describes the general size, architectural thrust and relative duration of a project’s size, scope and vision. Cathedrals are huge, typically planned to some degree, and take years (and occasionally centuries) to construct. Bazaars, on the other hand, tend not to be very large (one or two streets in a village or filling a marketplace) have no architecture per se, and spring up overnight and disappear just as quickly. Booch (et al) in UML: a user’s guide refer to this as the difference between a kennel and a house. It’s possible for a single person to make both, but the two take different levels of planning and different mindsets.
The old Unix mindset of many small flexible tools (awk, grep, fetchmail, nm, tar, etc) doesn’t work when you want a word processor and a project management tool to be able to interact in rich flavors with each other. Not only are each of the two previous examples difficult to write and finish with a capital D, the architecture that allows them to interact is also similarly hard, with a capital H. To give you good examples, check out AbiWord and KOffice. These are good tools, and will be even better once they are finished, but they are multi-year, multi-person projects even before 1.0 is out and about.
My thrust is that OSS could do with the idea that software architecture is essential to not only getting to 1.0 quicker, but also allowing 2.0 and 3.0 to occur in the future. Getting 1.0 finished with the help of others coming in cold to your project is an essential portion of a large- scale OSS project. Try this: pick a large scale OSS project that you are unfamiliar with, like mozilla, XFree86 or KOffice and add a single feature from the TODO list or fix a critical long standing bug. How long did it take you to discover where that feature should exist in the tree and understand how the code hangs together. This is the warm up time. My premise is that architecture shortens this time, and can make all bugs that much more shallow.
With a clear architecture, anyone can say “I’ll do X” and go away and write X, test X, and integrate X into your source tree and it’ll work. Without it, features get grafted onto the side, ill-fitting, and require a fair amount of code rejigging, wasting valuable developer time.
I’m planning in presenting a paper on this concept, and how to successfully add software engineering constructs and architecture (conceptual integrity) to OSS projects without diminishing the best parts of “release early, release often” methodology.
The trick is to make it sound fun, and not like a trip to the grown up’s room or the dentist.
Leave a Reply