Open Source, a Phenomenon of Generation Changes in Software Development: The Case of Denshin 8 Go

: Success in software development is not simply “a person” or “a team” succeeding in development, but rather the execution of a smooth “shift to the next-generation” of developers, who continuously upgrade a single software product over a long span of time. In this case, different generations of developers share the source code. This paper analyzes this process using “Denshin 8 go,” Japanese free software as one example. Initially, the original creator, Ishioka developed Denshin 8 go single-handed as closed source software and succeeded in motivating users through frequent upgrades. Several years after the initial release of Denshin 8 go Ishioka lagged behind in much needed upgrades, but one user group continued to use Denshin 8 go and was eager to improve the software. He disclosed the source code to the group, which in turn carried forward the process of development. As this case shows, the viewpoint that alternate generation of developers outside of a single company is caused by success in software development is known as “open source” software development. However, the reverse is not necessarily true. That is, simply becoming open source does not guarantee successful development.


Introduction
Success in software development does not simply mean the development of superior software in terms of function and stability by "a person" or "a team." According to Ikuine and Fujita (2013), who hold that continued development provides the ultimate guarantee for software quality, success is the smooth shift to the next-generation of developers to continuously upgrade a single software product over a long span of time. Superior software is merely the result of continuous upgrades.
However, existing research on Open Source Software (OSS) have misinterpreted the meaning of success. This indicates that focus is solely placed on the finished quality of the software and discussions are limited to whether the software is open source. In addition, they contend that unless the software is open source, it will not attract users with a high development competence, and without shared source code, development communities will not be established. They also assert that open source is a truly effective path to successful development and the establishment of development communities naturally makes the software "future-proofed" (Raymond, 1997).
Therefore, the OSS guidebook (Fogel, 2005;Sandred, 2001) does not cite project survival methods when discussing the methods of Open source, a phenomenon of generation changes in software development start-ups and management of projects. Research analyzing OSS success factors (Bonaccorsi & Rossi, 2003;Lee, Kim, & Gupta, 2009;Midha & Palva, 2012) only focuses on developer motivation and the continuous users, paying no attention to project survival. 1 Even longitudinal studies on OSS projects (Sen, Singh, & Borle, 2012;Subramaniam, Sen, & Nelson, 2009) suggest that type of licensing agreement is a success factor. 2 Although the initial development of Denshin 8 go (pronounced 'denshin hachi-go'), a leading example of Japanese free software, was completely closed source, a user group was handed over the source code and continued the process of development. Because the original creator, Takamitsu Ishioka, was able to succeed in motivating users to cooperate in the development process through early and frequent upgrades, the users continued to submit requests and reports even when Ishioka lost his zeal and lagged behind in much needed upgrades. Ishioka decided to provide the source code to a user group that had continued to use and display eagerness to improve Denshin 8 go. The source code was shared with the user group in accordance with the change in developer generation, that is, from Ishioka to the user group, and although it was incomplete, to a certain extent Denshin 8 go had become open source.
The case of Denshin 8 go demonstrates the following two points: (1) Software development success means the continuation of development and upgrades, of which superior software is merely a by-product. (2) Open source is a phenomenon observed during the shift to a next-generation of developers, which is a process that accompanies continued development. This paper analyzes the process involving a shift in developer generation by examining a case study based on interview surveys with the original creator of Denshin 8 go, Takamitsu Ishioka, and the main members of the user group that "inherited" the source code from Ishioka. The interview data was appropriately supplemented with data obtained from additional email surveys, the Denshin 8 go official website, and release notes.

Case Description: Development of Denshin 8 Go
Denshin 8 go is an email program for Windows that was developed by Takamitsu Ishioka. The volunteer user groups Den8club  (Table 1).

Motivation to develop Denshin 8 go
Ishioka was motivated to develop Denshin 8 go owing to a desire for a "user-friendly email program" and the mild motivation to "make money." Ishioka began using email in 1994 after joining the internet connection service for individuals provided by Internet Initiative Japan. At the time, he found every email program for Windows extremely inconvenient to use. In the spring of 1995, he began thinking "I am going to create a user-friendly email program for

Development process of Den8club and Den8dev
The composition of the development process executed by Den8club and Den8dev largely consists of the following three phases, which is a cyclical process.
(1) Patch creation, (2) Integrating patches and translating them into binary files by official builders, (3) Release and reception of requests and operational reports. Users submitted requests and operational reports to the mailing lists of Den8club and Den8dev, after which Yoshihito Obara, one of the official builders, compiled them into a "WishList." The official builders and the members of Den8dev created patches as per requests and reports that they agreed upon by using the WishList as a reference. There were cases in which the developers created patches to resolve problems, discovered while using Denshin 8 go as users. In addition, there were cases in which patches were created for RFC compliance and to countermeasure gaps in security.
Official builders, Kenichirou Nakamura and Takahiro Fukui, integrated the patches by referencing the WishList, converting them into a binary format, and then uploading them to the server. New versions with patch integration that had unstable performance and carried the risk of data loss were released as alpha versions only to Den8dev members. Once the risks were eliminated and the program was deemed safe, it was released as a beta version to Den8club members, which was as good as publicly releasing the program.
Den8club and Den8dev members were responsible for running performance tests of the alpha and beta versions, and the submission of bug reports and revised patches. Based on this, the official builders reintegrated the patches and fixed the bugs, after which a final version was released to general users.

Early and frequent upgrades of Denshin 8 go
Ishioka and Den8club were able to achieve early and frequent upgrades for Denshin 8 go.  is not a necessary condition for success of software development. In the case of "Xara Xtreme," 8 the source code was disclosed for everything but the core rendering library (CDraw), although development was actually discontinued six months after the source code was disclosed. In the case of the "OpenDarwin" 9 project, that went four years after releasing their source code without achieving its goal, Apple Inc. has always managed the latest versions of source code. These two failures were due to problems other than the open source issue and licensing imperfections. Xara Xtreme was upgraded a mere five times, while the OpenDarwin project was unable to even release its own package. Although early and frequent upgrades are effective for strongly motivating users to cooperate during the development process , both Xara Xtreme and OpenDarwin failed because they were unable to achieve this.
After the first release of Denshin 8 go, Ishioka was able to release 33 upgrades in just over two years ( Table 2). The continuation of early and frequent upgrades in the early stages of development served to intrinsically motivate users (Deci, 1975), who continued to submit requests and reports even one year after the number of upgrades had dropped. If upgrades are equivalent to external rewards, a decline in the frequency of upgrades means that user motivation also decreases, and thus, the submission of requests and report would likewise decrease. and self-determination, which further intrinsically motivated users.
Denshin 8 go is a case that exhibits the informational aspect of rewards (Deci, 1975, Proposition III). In fact, Raymond (1997) also points out the importance of a shift to a new generation of developers. It is important that "when you [the original creator] lose interest in a program, your last duty to it is to hand it off to a competent successor" and it is necessary to "establish that it was in a safe pair of hands." The "proof" described by Raymond, is the conscious volition of continuous usage and enthusiasm to improve the software.
There is a likelihood of criticism that users possessing the will and eagerness do not necessarily have a high level of development competence, required to inherit the source code. However, we may consider that if the developer incorporates consecutive user ideas and steadily refines the software, those who perceptively detect this are the very users that possess a high level of development competence. Actually, when Ishioka was developing Denshin 8 go as closed source software, there were users who sent Ishioka the source code that could be directly incorporated into the software. From this, we learn that simply opting for open source software development does not ensure success.