Previous    Table of Contents    Up    Next

Code Issues

One of the first hurdles an open-source project faces is whether the code is complete and builds a working application. The classic complaint about Mozilla in its early days was that the source code Netscape released was incomplete and could not make a working web browser. The Mozilla team was committed to the work, so the project continued. Once a working browser began to emerge, more casual contributors have also been able to participate.

This is also a common problem for small projects that are started because someone has a cool idea: A group of people may exchange messages about the idea and suggest ways to improve it, but somehow no one ever gets around to writing any code! Remember that open source only works to incrementally improve what's there--if you have only design ideas, then that's what the community will improve. Someone needs to write the code for a minimal but working version before the community will contribute any code.

A second hurdle is making sure that the user succeeds when trying out your application for the first time. This was a noticeable problem with Jini, not because of a problem with the Jini code but rather because of a problem configuring Windows systems to properly support multicasting. The lesson here is that even though your code is fine, problems with other software may cause your project to suffer. You need to go to some lengths to anticipate initial usage patterns and skill levels of the users when code is released to the community. In the Jini case, it was expected that mostly Solaris users would try out Jini and that any Windows users would be able to figure out how to configure multicast properly. This expectation proved to be false on both counts.

Another stumbling block occurs when outside developers have trouble navigating the source code. This could be because the code is too difficult to understand (in which case it should be rewritten), there is inadequate system documentation, or the code base is too large. Developers who want to work on the OpenOffice project have a steep learning curve due to the tremendous amount of code involved. This is a particularly common problem as a project moves from being proprietary to open source because of the vastly different levels of developer involvement--even an incredibly well-documented proprietary project still assumes a full-time commitment from a new developer.

Marc Fleury and Juha Lindfors wrote in "Enabling Component Architectures with JMX" about how modularity increased open-source productivity in the JBoss project:

Modularity in open source is not just a good idea. Modularity is the only way a project can mature. Successful open source projects are usually measured by the number of people that participate in the development. It is common for very successful teams to have a tightly knit core team of developers working on core functionality, but the key to growing the codebase is to enable lots of developers to work on modules around the core.

JBoss 1.0 was near completion when the core developers came to a simple conclusion: it was too hard for the casual developer to come in and contribute over the course of a week. One would have to spend at least a week to understand the code before making any contribution. The situation was typical of second generation open source projects: lots of people wanted to participate but very few could actually do so.

For the third iteration, JBoss embraced JMX. Within a week, an alternate SOAP-based invocation layer was submitted to the JBoss group. Modularity is needed for open source development and management. JMX is a natural way to enforce modularity in a design. The increased productivity and the ease of component integration to the server has made JBoss and JMX a success.1

A related problem cropped up in the JXTA project. The JXTA source code was deliberately released early so that the community could help design it. This led to some developers being confused about which aspects of JXTA were not yet defined and which had just not been documented yet. Once adequate documentation was written that made this clear, the discussion was able to move forward smoothly.

A different type of problem can happen when a project has a slow release cycle. One way that the outside world judges how well a project is doing is by how long it has been since the last release. If a project goes too long without a release, people will start to consider the project dead or a failure. For example, many people thought that the Mozilla project was in trouble after its first year because no working browser had been released. The frequent releases starting in mid-2001, leading up to version 1.0 in June 2002 and continuing since, have dispelled this feeling and now people outside of the Mozilla project have good evidence that it is alive and making progress.

If your project has not released anything for a long time, you should consider putting less into your next release and trying to do smaller, more frequent releases. You should also make sure that your project website is updated regularly--a stale website is another indication of a dying or dead project.

Another potential problem relates to subprojects. As we discussed in the earlier section Don't Needlessly Duplicate an Existing Effort, there is usually only one open-source project in a given area. This also applies within an open-source project: Once someone contributes a new module to your project, it will be difficult for a similar module to compete. Stated another way, the first code to show up usually wins.2 For example, as part of the Apache XML Project, the Xerces XML parser appeared first making it difficult for another XML parser, the Crimson subproject, to be adopted. In fact, the best parts of Crimson have been merged into the Xerces code base and work on the Crimson subproject has been halted.

A problem comes from believing that developing the code is all that is required. If all of your attention is on developing the code, you are likely to lose track of your main business goals. For example, if ubiquity is a goal, then marketing the technology to potential partners should have a high priority--internal development resources should be focused on helping partners succeed. If you can get a large company such as IBM or HP to adopt the technology, you can be sure they will contribute their own developers to help work on the code. Unfortunately, the natural tendency is to try to do everything yourself, and so larger opportunities are often neglected.

Another way this problem can hurt your project is if the developers, both internal and external, are the only ones to decide on the project's future direction. The whole idea of open source as a meritocracy focused on coding tends to disenfranchise anyone who does not contribute code, which means that users, UI designers, marketing people, and the like are often not able to fully participate. This results in software that is designed by developers for developers, and this is why much open-source software is not appropriate for the general public. If you are seeking "world domination," then this can be a major problem that you need to overcome.

One way to make the focus go beyond the code is to actively make roles for nondevelopers such as UI designers and documentation writers. For example, NetBeans has a communitywide mailing list dedicated to the design and discussion of UI issues. There is also a NetBeans project focusing on UI development and issues, plus a process through which other developers can get UI design assistance from the members of the UI project. When the NetBeans project first started, there was a hesitancy to add nondeveloper roles like this because that wasn't something that the high-profile open-source projects such as Apache or Linux did. You may encounter similar resistance.

It should be noted that the UI community traditionally has worked in a test-first design atmosphere in which usability testing takes place before committing anything to code, so there could be a basic mismatch of working styles between your UI folks and the open-source developers. This has been known to hurt open-source projects in general, so you should make sure that the UI folks you include in your open-source project are educated in continuous (re)design and buy into the approach.