Skip to main content

Open Source Developer Myths

Posted by daniel on December 22, 2003 at 9:11 AM PST

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.

His ONLamp article href=""> Myths Open
Source Developers Tell Ourselves leads off href=""> Also in Java
. The first can be frustrating. You have a good idea and get busy on the beginning of an implementation. You post your nascent project and hope that others with similar interests will come and help make it better. chromatic writes that it is "important to write and to share good software. Be content to produce a useful program of sufficiently high quality. Be happy to get a couple of patches now and then. Be proud if one or two developers join your project. There's your success."

Although you may hope that "Publishing your Code Will Attract Many Skilled and Frequent Contributors", chromatic turns the tables and asks "When was the last time you reported a bug? When was the last time you tried to fix a bug? When was the last time you produced a patch? When was the last time you told a developer how her work solved your problem?"

You can dispel many of the other myths by similarly considering how you behave with code that you don't author. WIth that in mind you can see the folly in the adage that "The Best Way to Learn a Project is to Fix its Bugs and Read its Code". Also, chromatic reminds you that since so many more of the people that find your project will use the code than contribute to it, you need to pay particular attention to installation and configuration of your software. "Potential users become actual users through several steps. They hear about the project. Next, they find and download the software. Then they must brave the installation process. The easier it is to install your software, the sooner people can play with it. Conversely, the more difficult the installation, the more people will give up, often without giving you any feedback."

Randy Miller has been thinking about what's coming in the next version of UML. Take a look at part 1 of his Borland whitepaper on What's New in UML 2.0? Many of the changes are in naming or the diagrams themselves, but one of the biggest areas being addressed is "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."

In Projects and
, the Jini community's Frank Sommers has a new article in JavaWorld magazine on Jini Extensible Remote Invocation (JERI) framework. He writes that JERI "provides programmatic access to each layer of an RMI call via an API and allows an RMI service deployer to choose the RMI implementation most suitable in a deployment scenario [and] RMI calls can now adhere to any security requirement." He also makes the following important point about the philosophical differences between using RMI and SOAP.

From a Java programmer's viewpoint, SOAP and Java couldn't be more different. SOAP defines a way to encode textual and binary data in XML data structures; Java code, on the other hand, can express not only data, but also algorithms that operate on data. While SOAP-aware APIs, such as SOAP with Attachments API for Java (SAAJ) and Java API for XML-based RPC (JAX-RPC), can make a SOAP-based method invocation syntactically appear as if that invocation was a simple Java method call, no SOAP-aware API can mask the semantic difference between Java and SOAP.

When a SOAP message traverses the network, that message is confined to carrying markup tags that might convey some semantic meaning at a distant network location. For SOAP to work, that distant network node must first be able to interpret the semantic markup contained in a SOAP message and, second, must have the available code to operate on the SOAP message data. Interpreting data elements and performing a set of agreed-upon operations on that data form the core of a SOAP-based Web service protocol. Current XML-based Web services define SOAP protocols for specialized problem domains such as Web service registries (Universal Description Discovery and Integration (UDDI) and ebXML) or electronic data interchange (EDI).

In contrast to SOAP, RMI relies on Java code as a unit of information exchange in a distributed system. As a programming language, Java encapsulates both data and code. That difference allows RMI system participants to share only the semantics of objects expressed in Java code. The protocols each object uses for network communication remains an implementation detail hidden from other network participants. That single requirement, in turn, raises the abstraction level of a distributed system from protocols to interactions between objects. That higher abstraction level lends network programming an object-oriented flavor and affords a close semantic match between local and network programming.

Today the Java Communications community homepage is featuring the project SIP Communicator - Pure Voice over IP Java Agent. It is a Java SIP User Agent that "supports both audio and video [and] Works over IPv4 and IPv6. Firewall support and Instant Messaging features are being currently developed [and] IM features will soon be added"

I'm sure we'll have more to say about it later, but James Gosling's announcement of the T-shirt hurling contest is at the top of today's href="">Weblogs . Michael Champion continues his look back at the XML 2003 contest with reflections on the Adam Bosworth Keynote. (sorry Michael - the T-shirt contest had to lead)

One of the themes from Bosworth's keynote was a return to simplicity. Champion reports that "Bosworth notes that one of the negative aspects of the current XML world is that the KISS (Keep It Simple, Stupid) principle is being widely ignored, as XML and Web services technologies are becoming extremely complex. Bosworth has pointedly noted the complexity of W3C XML Schema and XQuery in the past". Michael notes that "It's heartening to see more and more people pick up on the theme that the XML family of specifications is too complex, since I've been beating this drum for a long time now. It's definitely time for some serious refactoring of the the family of XML specs, and that won't happen until more people of Bosworth's stature start telling the unpleasant truths about what a few thousand person years of Design By Committee will do to a technology that used to be simple."

The idea that the feedback has picked up on are " JXTASpaces (sort of tuplespaces/Javaspaces using XML rather than objects) as a way of bridging the gap between the web services ideas that Bosworth talked about and the REST stuff that intrigues him. (Williams doesn't make the link to Bosworth in the posting, but has done so privately) . Kimbro Staken picks up the thread and mentions how an XML DBMS that supports XPath can make the template lookup feature of tuplespaces easy to implement if XML documents are the "tuples." I think they are definitely on to something here -- See Robin Cover's summary of some technologies and discussions, including some comments by me. The one point that's most relevant to synchronizing mobile devices is that coordination via "spaces" allows loose coupling in time as well as space -- not only can components in a distributed system employ different platforms, languages, and native data formats, they don't even have to be running at the same time."

Speaking of distributed apps, M. Ranganathan's latest entry is titled Logging of causal distributed application behavior. He suggests that we "add a standard log format to capture causality in distributed applications [, and ] build tools for correlation of distributed logs without needing to synchronize wall clock time [,] and finally, I would love to not employ the infamous new Exception().printStackTrace to capture stack traces in log files (which invariably frightens unsuspecting users)."

In today's News

Registered users can submit news items for the href=""> News Page using
news submission
All submissions go through an editorial review by news director Steve
Mallet before being posted to the site. You can also subscribe to the
href=""> News RSS

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href=""> events submission
All submissions go through an editorial review before being posted to

This blog is delivered weekdays as the href="">Java Today
feed. Once this page is no longer featured as the front page of href=""> it will be archived at href=""> You can
access other past issues in the href=""> Archive.