Requirements

A WikiDE is a combination of two systems: A wiki system and a web-based IDE. A realization of a WikiDE must therefore fulfill the requirements for both types of systems.

Section 1.1.4 describes from a technical perspective how a newcomer joins a FLOSS project. This process starts with a process of programming, which consists of the three actions Modify source code, Build the application, and Test application behavior. The software developers repeat these three actions until the application works as expected. An IDE supports software developers in this process of programming. Each of the three actions involved in the process of programming results in a requirement for an IDE. An IDE therefore comprises at least three different subsystems to realize these requirements: A code editor enables software developers to edit the code, a build system builds the application executables, and a debugger allows the software developers to debug the application. [RC04; Har09, p. 5]

Wikis disperse constructive work over a high number of contributors. In this manner, each contributor needs to contribute only a little to still yield a considerable accumulated contribution. This works only if people can easily become users of the wiki project and users can easily become

4.1 WikiDE Concept contributors. Section 1.3.7 discusses the effects of lowering contribution barriers in FLOSS projects to wiki-like levels.

The authors of the Portland Pattern Repository’s Wiki have also discussed requirements of a WikiDE [Aut12]. These requirements contain among other aspects extensions to a WikiDE that may lower contribution barriers but are not strictly necessary to realize a WikiDE. They also imply that the primary concern of a WikiDE would be to modify its own source code. This thesis does not impose general restrictions on the type of development project the WikiDE is used for. Consequently, their findings differ from the findings in this section.

Self-administration

If a central administration decides who can join a project as a contributor, the number of contrib- utors can grow only with the speed the central administration can handle. For the exponential growth of the number of contributors seen in many wikis, the administration must grow with the contributor size. This is only possible if the contributors also handle the administration themselves.

Some wikis realize this with a policy that allows anonymous users to edit content. In this case, all users administer themselves. Users then decide on their own where to contribute. Other wikis require users to register before they can contribute. In this case, registration may be an automatic process that requires no administrative intervention. The system may check that new contributors have a valid email address. Corporate wikis may also integrate with a corporate user directory. In this case, the corporate wikis reuse the administration of the corporate user directory. These corporate wikis also require no extra administration.

A WikiDE may use any of these techniques to realize self-administration. The growth of an on- line programming site without self-administration is limited by the capacity of the administration.

No Installation

As pointed out in Section 2.9, setting up a development environment is currently one of the most important contribution barriers. Wiki contributors are not required to install any software on their computers. Instead, they modify the wiki content using their web browsers.

This requirement must hold true also for a WikiDE. The WikiDE must relieve newcomers from the various tasks required to prepare their computers for the software development project. Thus, a WikiDE must automate the first two actions in the contribution process described in Section 1.1.4: Download the source code and Configure build environment.

Code Editor

Writing the source code for software and writing text in a natural language are special cases of editing text. Editors for writing source code for software are referred to as code editors, while editors used to write natural language text are referred to as word processors. Word processors provide only basic meta information about the text like orthographic checks at the time of writing. Code editors on the other hand provide extensive syntax highlighting: Language keywords, types, numbers, identifier, and other types of terms are each displayed in different colors to improve

the software developers’ understanding of the source code. Additionally, code editors highlight contextual information, from basic information like which opening and closing brackets match together, highlighting other occurrences of a currently edited variable, and API documentation of the method currently edited. [MP09]

Software and hence their source codes are written and maintained by humans. Additionally, a compiler or an interpreter must be able to automatically process the source code. Thus, source code needs to be human-readable and also machine-readable. Natural language only needs to be human-readable. It is therefore sensible for a code editor to show the human working on the source code how a machine understands this source code, i.e. provide features like syntax highlighting and suggestions for word completion. These features are necessary beyond the features of a word processor. Consequently, a WikiDE needs a code editor that fulfills these additional requirements beyond the requirements of the text editors in other wikis.

Immediate Feedback

All wiki users are treated as contributors. Therefore, all users can contribute to any part of the wiki’s artifact. This also implies that they can see the results of their edits immediately [Ebe+08, p. 11], without manual interaction with a group of wiki maintainers.

Most wikis offer a preview feature that allows the contributors to see the results of their edits before they are published to the other users of the wiki. With the help of the preview feature, contributors detect and correct errors that they have made while editing.

The process of programming with its three actions resembles this wiki editing process on a high level of abstraction. After the software developers have modified source code, the IDE creates the executables of the component. There are two purposes for the creation of the executables: First, the software developer tests whether the modifications in the source code actually cause the desired change in the component. Second, end users of the component need the executables to use the component. These two features of an IDE map to the preview feature of a wiki and the eventual publishing of the edited content.

For the first purpose, software developers run the component itself if it is an application or run a test application that uses the component if it is a library. Then they interact with the running application. While interacting with the running application, software developers may detect only those failures that crop up in the user interface. Software developers attach a debugger to the running application to detect failures that do not crop up immediately in the user interface. The position in the source code of the user interface at which a software developer first detects a failure is not necessarily the position of the causing defect. Instead, an underlying module may be defective. The underlying module brings the execution in an invalid state, but this becomes visible in the user interface only at a later point. Software developers also use a debugger to find the defective source code in the underlying module.

These two purposes to create executables also manifest in WikiDEs: First, developers see whether their modifications do what they intended them to do only when they run an executable application that incorporates their modifications. Second, for other users to give feedback to modifications, the other users must be able to test these modifications. For these tests, they need to run an executable application that incorporates the modifications.

4.1 WikiDE Concept sufficient impact on the user interface. Users need a debugger to find and fix defects deep within the component. If a WikiDE does not include a debugger, defects in the user interface may still be fixed. A build system is therefore a requirement, while an integrated debugger only increases a WikiDEs application range. A debugger is therefore an optional component of a WikiDE.

Version Control

Wikis usually store a list of historic versions for each web page. Each historic version stores the content, author, and date of its modifications. Users can access this information and revert changes back to a historic version. If contributors know that there are backups, they are more encouraged to change the content. They can rest assured that even if they make a fatal mistake, it will be easy to correct afterwards [LC01, p. 324].

In software development, an atomic modification to the source code may take hours of work and the modification may span days or weeks. This can happen when software developers restructure the architecture of the component or when a modification to one code file requires modifications to dependent code files. While the modification has started but is not yet finished, the behavior of the whole component may be different than intended or the component cannot even be built.

Historic versions of source codes are usually stored in a VCS. Because of the long time span an atomic modification may take and because a single syntactic error can prevent the whole component from building, there are two major differences between the way VCSs store historic versions of the source code and the way wikis store the historic versions of its pages.

First, wikis store historic versions per web page. A web page of a wiki corresponds to a code file, as both of these store exactly one uninterrupted text. However, VCSs aggregate code files into so called repositories. Every repository has a list of historic versions. Depending on the VCS in use, a repository may not only aggregate modifications to code file contents but also additions, deletions, or movements of whole code files. If a modification of the component requires modifications in multiple code files, this can be realized as one atomic modification to the repository. This avoids unstable intermediate versions, where one side of an interface has been changed but a resulting change to the other part is not yet stored in the VCS.

Second, VCSs store the historic versions of a repository in multiple dimensions: There can be multiple lists of historic versions of each repository. Each such list is called a branch. Each branch has a common ancestor with every other branch. Software developers can also merge multiple branches back to a single branch. Software developers may create a new branch if they start a major modification of the application, for example. The new branch enables the software developers to split up this major modification into several smaller modifications that are stored as historic versions of the new branch. The other software developers can still continue with their work since they are working with the original branch and ignore the new branch. Hence, the software developers working on the major modification do not need to care whether their smaller modifications render some of the interfaces temporarily unusable or even break the build. Thus, multiple dimensions of historic versions enable the software developers to use the advantages of historic versions on a more fine-grained level.

A WikiDE must provide historic versions of the source code in the way a VCS does. Without the two major features explained above that distinguish a VCS from a standard wiki version

history, a WikiDE does not scale to high numbers of contributors, as they will disrupt each other with their contributions.

However, this imposes an additional problem a WikiDE has to solve: As there is no single latest version for a wiki page, which version of the wiki page shall the WikiDE display to the user? A WikiDE must therefore also come up with a strategy to choose the version of a wiki page for displaying on every access to wiki content. Similarly, new versions cannot be just appended to the list of versions in all cases. Instead, the WikiDE must have a versioning strategy: Which modifications create a new branch and which branches shall merge back together?

Code Reviews

In software development projects and especially in FLOSS projects, code modifications may be subject to a code review before they are added to the primary development branch [CH06a]. Code modifications must (i) not be malevolent, (ii) meet the quality standards of the project, and (iii) solve the problems they have proposed to solve or add the feature they have proposed to add. Code reviews ensure that only those code modifications are added to the primary development branch that meet all of the three criteria.

Wiki contributions resemble code modifications in that they may also meet or not meet any of the three preceding criteria. Wikipedia calls contributions that validate the first criterion “vandalism” [P*Wik16c]. The second criterion is less important in wikis, as the quality standard can be improved by others later [P*Wik16a]. Contributions to wikis may also be checked for relevance, which is equivalent to the third criterion [P*Wik15c].

If a wiki contribution fails at one of the criteria, it is usually sufficient to revert the wiki page afterthe contribution that failed the criteria. Software modules however depend stronger on each other. For example, if a malevolent modification was temporarily accepted for inclusion in a component, builds of the whole component may fail until reversion. Even worse, the component may contain a virus that infects the computers of users of the component. A low quality code modification may decrease the whole application’s stability. Additions of the wrong features may decrease performance or usability.

It is therefore critical to review software modifications before they are included in the primary branch of the application’s VCS. This is also a requirement for WikiDEs, although it seemingly contradicts other requirements like Immediate Feedback.

IDE Compatibility

Desktop IDEs are sophisticated applications that support developers in a broad range of devel- opment activities. The Eclipse IDE without any programming language support, for example, has a code base of 2 521 174 lines of source code at 2016-03-09 and Open Hub estimates about USD 40 million of development cost for the Eclipse IDE [P*Ope16a]. A WikiDE must fulfill the requirements of a wiki in addition to the requirements of an IDE and may therefore be less sophis- ticated than a desktop IDE. There is no general restriction that keeps a WikiDE from becoming as sophisticated as a desktop IDE, but this may take years of development. In the meantime, desktop IDEs are generally more powerful tools for software development than WikiDEs.

4.1 WikiDE Concept However, a WikiDE has advantages over desktop IDEs: It allows software developers to join a software development project more easily. For senior project contributors, this is not an advantage for their personal development experience, as they have already joined the project. They will therefore likely prefer a desktop IDE over a WikiDE for the reasons mentioned in the previous paragraph. These senior project contributors are essential for ongoing growth of the project [KK10].

Therefore and at least until WikiDEs have matured to the level of desktop IDEs, software projects should not rely on WikiDEs exclusively. A WikiDE system must therefore be compatible to other IDEs. If desktop IDEs can access the source code through the VCS of the WikiDE, the requirement is fulfilled. Compatibility is further increased if the WikiDE shares a project file format with common desktop IDEs.