Open Source Developer Myths: If you write it, they will come. This is the first of many myths that chromatic explores in his look at assumptions that open source developers work under. » Read more

Xml 2003 Reflections - Adam Bosworth Keynote: Some thoughts, and links to other discussions, inspired by a speech given by Adam Bosworth last week. Topics touched on include the KISS principle and its breakdown in the XML world, hopes that Father Darwin wil set things right, the challenges of effectively using low-powered mobile devices in an internet optimized for fat pipes, and spins off into a discussion of the ideas behind JXTASpaces as an alternative to the competing distributed object and REST approaches to this kind of application. — Michael Champion

Myths Open Source Developers Tell Ourselves
You've open sourced your project so that people will check in their bug fixes and decided that you don't need to provide docs because people can just read your source code. Stop, before you go further check out chromatic's ONLamp article Myths Open Source Developers Tell Ourselves . He concludes, "Making your source code available to the world doesn't make all of the problems of software development go away. You still need discipline, intelligence, and sometimes, creative solutions to weird problems. Fortunately, open source developers have more options. Not only can we work with smart people from all over the world, we have the opportunity to watch other projects solve problems well (and, occasionally, poorly)."

What's New in UML 2.0 part 1
Randy Miller has written a white paper on What's New in UML 2.0 . Some changes are as simple as the use of different names (nodes in Activity diagrams are now called actions instead of activities). When diagramming exception handling the try block will be contained in a UML protected node while the catch block will be in a UML handler body. The biggest change is the process called "UML Conformance". There are 38 defined compliance points and an implementation may choose from the options: no compliance, partial compliance, compliant compliance, and interchange compliance. There are also classifications of an implementation as a whole where "Class diagrams, Activity diagrams, Interaction diagrams, and Use Case diagrams are necessary for basic compliance. State diagrams, Profiles, Component diagrams, and Deployment diagrams make up the intermediate level. Actions and many advanced features make up the remainder of the material necessary for complete compliance."