START WITH OPEN SOURCE
3.2 OPEN-SOURCE SOFTWARE (OSS) DEVELOPMENT
Open source is a special development paradigm. Without budget constraints, customer pressure, and a schedule to meet, developers, users, and project competitors can speak equally. Projects are free to grow and even to produce child projects. The sky is the limit. Any part of the project canvas can be virtually extended so that other programmers can later add other things. If someone tries to add something malicious, theres a whole open community checking the work. This is the Bazaar model (Raymond 2001) for OSSD where no exclusive group controls the development; everyone who is inter- ested in the development can take care of the project.
In contrast to the bazaar model, thecathedral modelmakes source code available, but the development is restricted to an exclusive group of pro- grammers. Either way, it is the products themselves that have caught our eye.
Many companies have adopted these products for commercial applications and governments around the world have officially supported the use of open- source software in civil administration, indicating that the open-source products have now come to be recognized in terms of not only software quality but also maintainability.
Between the cathedral and bazaar models there is a hybrid, the applica- tion kernel maintained by a group of programmers, like the cathedral model but where anyone can develop different open source plug-ins.
OPEN-SOURCE SOFTWARE (OSS) DEVELOPMENT 65
As there can be thousands of open-source software projects in or between the bazaar and cathedral models, it is not possible to generalize about open source. In this section we will therefore look at some features that may not be typical of every open-source project but that are helpful in contrasting it with the ways we develop the commercial development projects (often referred to asclosed-source software projects).
Some of the features of open-source software projects are listed in Table 3.3.
3.2.1 Software Cloning*
Cloning in genetic engineering is the process of recreating an identical copy of DNA, the nucleic acid containing the genetic instructions for the biological development of an organism. Thus, cloning does not copy us (i.e., human body and mind) but our DNA. What is the DNA of enterprise software applications?
If we get the requirements for an existing system we can use them just like DNA to rebuild a similar system using other computer languages on other platforms. The two systems would have a very close functionality from a user perspective. The functionality of cloned applications should be of interest to us; otherwise, we would not clone them.
Why do we clone software? There are many reasons. In some cases, software applications that have been cloned should be either closed-source software or software built with many technical constraints so that further modifications are not that feasible. When such software applications interest programmers, it obviously must be the functionality such as application requirements and/or better performance, rather than the language used to write it. This provides us with a clue as to what motivates open-source developers to join a project and to spend time reading and writing code. Even though some programmers are not involved in the development because they are not familiar with the language used to build the software, they still enjoy providing their opinions and reporting bugs.
TABLE 3.3 4Ps in Some Open-Source Software Projects 4Ps Features of Some Open-Source Software Projects
Product Software cloning (or requirements cloning); software quality
People Ugrammers
Paper Same as for product and people, above Process Starting process, rapid releases
*The term cloning has been used in the open source community. For example, the early version of Miranda IM (Miranda Instant Messenger) regarded itself as a minimalist ICQ clone.
66 START WITH OPEN SOURCE
Example of Software Cloning
In 1991, Linus Torvalds, the initiator of the Linux project, needed a version of Unix for his PC. To improve its functionality, he made it known what he wanted to do and invited feedback from those who were interested in the product (Pavlicek 2000). Whether Linux has evolved beyond the Unix family, it was a cloned application of Unix.
3.2.2 Software Quality
The big question in open-source development is how software that has been developed through the collaboration of volunteer programmers could possi- bly deliver quality as good as we can get from a well-structured team using well-defined development processes. The cloned application may imitate the functionality of what we are going to develop, but getting complete require- ments for software has nothing to do with code quality.
In terms of the number of developers, the Linux project has been recog- nized as probably the biggest project in the world. Ken Thompon, one of the principal creators of Unix, disappointed many open-source proponents by saying that he thought the quality of Linux varied drastically. Some of its source code was good, and some was not (Thompson 1999). This is just a sensible comment because after all, the software has been written by many different people.
Linux has often been assumed to be representative of all open-source projects, but it is in fact a uniquely large project, and writing operating systems is much more technical than doing other applications. We cannot generalize from Linux to other OSSD projects.
Stamelos et al. (2002), tried to quantify code quality in open-source development. One hundred applications written for Linux were studied using metrics such as cyclomatic complexity measuring the extent of linear independences (McCabe 1976) and vocabulary frequency measuring the sum of the number of the unique operandsn1and operatorsn2(Halstead 1975).
The results showed that the quality of code produced in these open-source projects was a little below the industrial benchmarking given by Telelogics Logiscope. Interestingly, as the open-source project is running continuously, the open-source code in terms of software quality could be a little more maintainable in the next release than closed-source code (Stamelos et al. 2004).
Few commercial software vendors release source code or testing reports to their clients. Without that information, we actually know little about their software quality. So we cant criticize it, but that doesnt mean high quality
OPEN-SOURCE SOFTWARE (OSS) DEVELOPMENT 67
code. In contrast, open source allows everyone to inspect the software quality at the code level. Obviously, we cant say on one hand that all open software is high-quality or on the other hand that bazaar-model-developed software is of a lower quality. To judge the quality of open-source software for use in commercial applications, we have to evaluate it project by project.
3.2.3 Starting Processes
Open-source software projects can have different starting processes. In some cases as just mentioned in software cloning, a single person (or a few known people) may begin by calling for public comments that arouse public interest.
The project can be of purely personal interest. It can also be a funded project.
In other cases, the source code of commercial or academic working software products is released to the public and becomes a new open-source project. One example is Mozilla. Open-source projects initiated and sup- ported by a number of organizations do not normally invite public developers to join the development, but what interested developers probably can do is to get involved in the customization and deployment of local language inter- faces, for example, as in A-tutor.
Figure 3.4 provides an overview of how open-source projects like Linux and Mozilla are initiated. Personal interest in a software product—whether that interest is one persons or a groups—is the driving force in stimulating and steering an OSSD project. In many cases, the interest is in what the
Personal Interest
Invitation to Public
Core Development by a Small Team
Commercial Products
(Closed Source Software)
The First Time Source Code Released to Public
On-going Open Source Software Development
FIGURE 3.4 Open source software development.
68 START WITH OPEN SOURCE
product should be or look like rather than in how the product can lead to the development of an OSSD project.
Public invitations on the Internet to developers to participate may lead to the establishment of either a small core development team or the quick development of a prototype based on feedback. At this time, the team must be small, perhaps just one person. This is because when the product is at zero, it is both difficult and unproductive to create software on the basis of many comments and too many people and code changes. At this stage, the main goal is to release the product, despite its incomplete functionality. Interested developers can then focus on the product. Thus, an open-source project is product-driven. Without the first release, many developers can only contrib- ute comments.
In other cases, closed-source projects that have probably been commercial products in the market are released to the public. This extends their user bases so that the companies can concentrate on providing professional services such as training and consultancy instead of selling software.
Software is purely artificial. It becomes less abstract only when we have experienced the use of software. In a word, zero-point collaboration, in which a group of people collaborate on a new artifact from the ground up, is difficult in a distributed environment.
Therefore, releasing source code is important in making others partici- pate and hence to build the team. The success of requirements for open-source projects is that developers need to have something from the ground up that can be downloaded, installed, tested, and so forth, and it does not seem possible to build things from the ground up in the open-source style (Sandred 2001).
3.2.4 Open-Source Development Community
Once the first release is available to the public, the project team will rapidly grow. Some developers actively build more submodules while some others just play around and suggest potential features to enhance the software.
Although this seems to have a structure of teaming, the OSSD team is just loosely coupled. The team has a higher degree of collaboration. Each indi- vidual can work on the product independently, accelerating its development in many areas such as debugging, performance tuning, refactoring, function- ality enhancement, and testing on different platforms, such as Chinese Windows. But it is less coordinated.
As a consequence, people could be individually reinventing the wheel for the same problem until someone reports her or his findings. Once a solution
OPEN-SOURCE SOFTWARE (OSS) DEVELOPMENT 69
(i.e., a program) is posted, the others would then look at the source for further improvement. In any case, effort can be duplicated, but others can build more on that program and later on release a more complete one.
Such low communication proximity makes the team work like a commu- nity, in which people feel the need to have a share in helping to build a software product and thereby having a sense of belonging to a group in the network where they live (having an identity, i.e., nickname; and social responsibilities, such as fixing their own program bugs once reported).
Surveyed from the open development community, open-source devel- opers can be classified in terms of the extent of involvements and activities.
For example, a project leader administers the overall project. Core developers manage concurrent version system (CVS) releases and coordinate others. On an either regular or irregular basis, codevelopers fix bugs, add features, submit patches, provide support, and exchange other information. Active users who probably install latest versions (rather than stable versions) submit their test reports and suggest potential enhancements. People outside of the above are free to examine the code and submit patches. When the cathedral model is adopted for the development, there could be a distinct difference between a developer raising an issue and some outsider raising the same issue (Xu and Madey 2004).
3.2.5 Ugrammers
No one likes to be responsible for more jargon, but we need a word to clarify the different and evolving roles of programmers and end users in the software world. Somewhere between a programmer and a user there is someone else, someone nameless. Armed with modern technologies and the knowledge of how to use them, these people are consumers who have become proactive. They are not easily satisfied with standardized products and are willing to let manufacturers know exactly what they want. Alvin Toffler, the author ofFuture Shock, coined a wordprosumer,which sounds likeproactive consumer,but he meant to combine producer and consum- er. We may now at last be seeing the birth of this hybrid creature. Similarly, as the roles of the producer (i.e., programmers) and the consumer (i.e., end users) blur in OSSD, we are seeing the evolution of a new, hybrid creature, theugrammer.
Before, for lack of time and other reasons, developers could not cus- tomize or add features to closed-source applications for their individual needs. Open-source software projects give them the opportunity to partici- pate in developing the application they are really interested in and a chance to have a wider impact. No longer just passive users but also active
70 START WITH OPEN SOURCE
developers, they are two-in-one. They areugrammers. Consider the follow- ing definitions:
Programmers—those who build the software but they are not end users Users (or customers)—those who will use the software (can be end users or
the end-user supervisors)
Ugrammers—those who build and use the software
Traditionally, programmers have deliberately adopted a variety of user perspectives on the systems they build. But they are not necessarily real end users. The two-in-one role of the ugrammer contributes to the success of a software project. The ugrammers complement each other as their develop- ment knowledge and user experience provide insights into the product they build.
Two-in-one makes software development a new paradigm. For example, requirements management is a key area of software project failure. Some management methods advise sign-off requirements documents while some suggest tight collaboration between programmers and users. For program- mers, experience of requirements management is often gained from domain knowledge that they previously gained from users. Ugrammers can use their own user experience to better evaluate requirements collected from others and can ask more insightful questions. This greatly enhances communica- tions between ugrammers and end users.
3.2.6 Participant Roles
The intuitive way to understand any software project is to simply classify involved members into two roles, customers (or users) and developers, as a percentage. In this way, we can easily compare an open-source project with a commercial software project and understand some fundamental differ- ences. How the percentage of project participants varies in the two roles tells us something about the projects. As illustrated in Figure 3.5, project participants in a commercial enterprise resources planning (ERP) project could be very separate. In this project, 25% of the participants take a pure developer role as programmers or system analysts. The rest play a pure end-user role, performing user acceptance testing, develop training manuals, and perform other tasks. In some commercial projects, some participants who adopt a 90% user role and a 10% developer role are often viewed as superusers. These participants can draw technical diagrams and even diagnose problems through systematic testing, which substantially helps the development.
OPEN-SOURCE SOFTWARE (OSS) DEVELOPMENT 71
In contrast to the abovementioned industrial project, the roles in many open-source development projects are any combination in any proportion of the programmer and user roles. In a case where the developers are the users (e.g., those who are involved in the development of Miranda-IM, Firefox, or Joone are the users), ugrammers can have a number of combinational dis- tributions with active users as shown for projects A and B in Figure 3.5.
There is currently no evidence as to how these distribution curves (A or B in Figure 3.5) correlate to the success of a project; however, we believe that having ugrammers in a software project, particularly in a distributed envi- ronment, helps bridge the communication gap between the developers and the users.
3.2.7 Rapid Release
By breaking down system functionally, we may rapidly release a software product from time to time. However, this has to communicate well with customers; otherwise, it may not be always desirable. Lets look at a real industrial case.
We met an IT manager in 2004 who implemented a JSPWiki (open-source software) as a departmental knowledge base. A Website can be used to distribute information. It does not facilitate collaboration between people.
But, when JSPWiki allowed people to log in and to easily edit available content, team members were able to follow documentation standards and then compile their working notes on practical experience and technical tricks directly on JSPWiki. This allowed departmental knowledge to be shared and reused (see Figure 3.6).
Percentage of people (including users and developers) involved in the projects
100 %
50 Open Source Project A Open Source Project B
Typical ERP Project
100% End User Role 100% Developer Role
Ugrammer Role (i.e. 50% Developer Role and 50% User Role) 85% Developer Role and 15% User Role
70% Developer Role and 30% User Role
85% End User Role and 15% Developer Role (often referred as Super User) 70% End User Role and 30% Developer Role (often referred as Super User)
FIGURE 3.5 Software project participant roles.
72 START WITH OPEN SOURCE
For example, someone may download a copy of JSPWiki to evaluate the functionality and plan for its implementation. The version was 2.1.134-alpha.
The installation was done, and the server was up. Everything seemed alright until the team started browsing around the software and they realized that there was no interface for changing the default password!
From a customer perspective, the software was not that complete. This would not normally happen in many traditional commercial projects. Some software houses may release incomplete software packages to clients for training purposes yet claim that the products are prototypes. Otherwise, as some end users areproblem pickers,they will just view any incompleteness as defects. This may potentially damage the image of professionalism of the software house.
But what doesthe expected completenessreally mean? It is all about the users knowledge and experience. For example, any software requires au- thentication. Users will expect to be able to change their login profile somewhere on the software, just as other software does.3As so many users often do an apples-to-oranges comparison, it is better to put a release off until we get basic things done from a user perspective.
Open-source development projects somehow reverse the logic. Take our previous example. When the user authorization is done, the module and its source code will be quickly released. The work at this moment is complete from a ugrammer perspective. The ugrammer can modify related configura- tion files to change any password; unfortunately, this might not be regarded as expected completeness by general users. In short, open-source projects release their work products by the completeness of source code FIGURE 3.6 Unlike many other types of websites, JSPWiki allows individual logins and editing.
3In agile software development, the developer and the customer truly participate in a software project. The customer can even prioritize a feature list for the developer.
Thus, there is no expected completeness.
OPEN-SOURCE SOFTWARE (OSS) DEVELOPMENT 73