Existing Wiki Systems for Programming

This section gives an overview of existing systems that fulfill some of the requirements described in Section 4.1.1 but lack support of others. Table 4.1 lists the systems analyzed in this section and shows which of the requirements they fulfill. Entries in the column Code Editor show Partial if the wiki system allows editing the source code but does not provide any extended features like syntax highlighting. Entries in the column Immediate Feedback show Partial if the wiki system builds application executables but provides no debugger. If the system provides a debugger, the column contains Yes.

Wikimatrix.org listed 140 different wiki applications as of 2016-03-09 [Cos16]. These wiki applications differ from each other among other things in their user interfaces, their distribution and editing licenses, the databases supported for storing their content, and in the programming languages used to develop the wiki application. Some of these wikis use a VCS as their backend and therefore fulfill the requirement IDE Compatibility. Even those using a VCS as their backend do not satisfy the requirement Version Control, though: Olelo [P*Men14] is an example for a wiki with a git [P*git16] backend. However, Olelo does not use the two additional features of a VCS required to fulfill the requirement Version Control. Olelo provides only a simplified view on the VCS version history, probably in order to maintain compatibility to standard wiki GUIs.

Some of the wiki applications allow their users to create not only human-readable content but also executable scripts within the wiki. Wiki applications with this feature are called Structured Wikis. Structured Wikis execute user-created scripts to process wiki content, for example in order to generate statistics. Because users create these scripts as they need them, these scripts are situational applications [Shi04]. Examples for Structured Wikis are XWiki [P*XWi16], TWiki [P*Tc16], and MediaWiki [P*Wik15a]. Situational applications do not require Code Reviews, as their primary users are also their creators. Also, the source code editing feature is restricted to the programming languages of the scripts. The scripts are executed only within the wiki, so common-purpose application development is not possible.

Wiki Business Query [AR08], Programming Wiki [HW09], and adessowiki [Lot+09] are wiki systems that allow source code as content within wiki pages. This source code executes on the server side and displays its results within the wiki page. Intended content comprises figures

Table 4.1: Wiki systems that fulfill part of the WikiDE requirements

WikiDE candidate Self-administration No Installation Code Editor Immediate Feedback Version Control Code Re vie ws IDE Compatibility

Wiki applications Yes Yes No No No No Yes

Structured Wikis Yes Yes Yes Yes No No No

Wiki Business Query Yes Yes Partial Partial No No No Programming Wiki Yes Yes Partial Partial No No No Adessowiki Yes Yes Partial Partial No No No

mHub No Yes Partial No No No No

Cloud IDEs No Yes Yes Yes Yes No No

XSDoc Yes Yes No No No No Yes

Galaxy Wiki Yes Yes Yes Yes No No Yes

XYLUS No Yes Partial Yes No No Yes

CrowdCode Yes Yes Yes No No No No

Software Forges Yes Yes Yes No Yes Yes Yes

4.1 WikiDE Concept and tables. The code can access data from databases or from other wiki pages. The wikis are intended to teach programming concepts to its users or for EUP. The wiki systems therefore do not support generic programming languages and are no WikiDEs in that they do not fulfill the requirements of Version Control, Code Reviews, and IDE Compatibility.

Sauer [Sau11] described the system mHub whose concept extends the concept of a Struc- tured Wiki. In contrast to Structured Wikis, the applications developed with mHub are not situational applications. Instead, these applications work as a middleware between an Enterprise Resource Planning (ERP) and the production machines of a factory. The concept does not explain how to authorize users for modification, therefore mHub does not fulfill the requirements Self-administrationand Code Reviews. Sauer does not describe how code editing works in detail. Thus, the requirement Code Editor is considered partially fulfilled. The concept of mHub does not provide solutions for the requirements Immediate Feedback, Version Control, and IDE Compatibility.

Cloud IDEs are code editors that run in the browser. Examples for cloud IDEs are Cloud9 IDE [P*Clo16], Koding [P*Kod16], and CloudPebble [P*Peb15]. The existing cloud IDEs are restricted to certain programming languages in order to provide the three core features of an IDE explained in Section 4.1.1, namely a code editor, a build system, and a debugger. For example, Cloud9 uses the browser’s ability to execute JavaScript in order to provide a debugging environment for JavaScript. Other programming languages can be edited, but they cannot be executed or debugged. CloudPebble specializes on apps for the smartwatch Pebble. The debugger emulates a Pebble. A Pebble is simpler than a smart phone or a desktop computer, considering for example that Pebble apps are only allowed 256 kB of data [P*Peb16]. Thus, emulating other target platforms than a smartwatch may bring additional challenges that CloudPebble did not have to face. Hence, the concept of cloud IDEs does not solve the problem of how to integrate the build of application executables into a web-based IDE. The concept cannot be generalized to most other types of application development. Some existing cloud IDEs satisfy the requirement for a Code Editor in a WikiDE for all kinds of application development, though.

Leaving the restrictions discussed above aside, the existing cloud IDEs are not wikis. They use multi tenancy, so the software developers using the system see only their own files. The project owners must actively invite other software developers before they can contribute to the project. Once a software developer joined the project, the software developer can change everything without preceding review. Thus, cloud IDEs do not fulfill the requirement of Code Reviews. They also do not fulfill Self-administration for the same reasons.

Aguiar and David [AD05] developed XSDoc, a wiki system that weaves source code and documentation together. Using a web service interface, desktop IDEs can access this content and thereby edit the source code in the wiki. XSDoc focuses on the integration of source code and documentation and not on lowering contribution barriers. For source code edits, the whole technical environment like an IDE and a build system still have to be installed.

Xiao et al. [XCY07] developed Galaxy Wiki, a wiki that integrates source code and docu- mentation with an IDE. With Galaxy Wiki, software developers can edit Java source code in the wiki with a web browser, they can also compile the application and execute it. Galaxy Wiki also integrates a debugger, which executes as a Java applet within the browser. Thus, Galaxy Wiki shows that a WikiDE can realize the requirements of a Code Editor and Immediate Feedback. The debugger concept of Galaxy Wiki cannot be used for most other languages, though, since most

languages do not execute within a standard web browser. Additionally, only Java applications for which the restricted Java environment within the browser context suffices can be debugged reasonably. Galaxy Wiki is based on the wiki system MoinMoin [P*Moi15], so the history of each source code file is only a single list, which does not fulfill the requirement of Version Control. Also, pre-commit code reviews are not possible, so Galaxy Wiki does not solve the problem how to fulfill the Code Reviews requirement and at the same time fulfill the apparently contradictory requirements of Self-administration and Immediate Feedback. By providing the source code via a web service interface, Galaxy Wiki maintains desktop IDE Compatibility.

Abbasi et al. [ASP10] designed the web application XYLUS as a cloud IDE for C# desktop applications. XYLUS is realized with Asynchronous JavaScript and XML (AJAX). Therefore, XYLUS can be used with standard web browsers and is platform independent. After a developer using XYLUS has modified the source code of an application, XYLUS builds the application on the server and starts a VM. The modified application is then loaded within the VM. The web application opens a Remote Desktop Protocol (RDP) session and displays the VM’s screen in the web browser. Keyboard and mouse input is redirected from the web browser to the VM through RDP, so the developer can debug the modified application running in the VM. In contrast to the debugger of Galaxy Wiki, this debugger concept applies also for languages that do not run within the browser itself. In their paper, Abbasi et al. do not explain where XYLUS stores the source code of the component and how changes to the source code are integrated into the store of the source code. Therefore, their concept provides no solution for the requirements of Version Controland Code Reviews. There is also no explanation on how the system’s users are administered. The concept also does not explain if and how XYLUS supports syntax highlighting.

LaToza et al. [LaT+14] also approached the goal of having many contributors to a software de- velopment project with CrowdCode. The method is quite different to those previously discussed, though, and its row in Table 4.1 reflects the features of CrowdCode only superficially. The system automatically generates tasks from the existing set of tasks and dispatches them to the developers participating in the system. For example, new code automatically spawns a task to specify and eventually write a test case. Developers may call functions that do not exist yet, in which case the system spawns a task to create the function. The system works with Self-administration and includes a Code Editor. It is no wiki in the sense that a user consumes content and may edit the same content with Immediate Feedback.

Software forges provide a set of typical software development tools, so new projects do not have to set up all of these tools individually. Furthermore, software forge services like GitHub [P*Git15c], GitLab [P*Git16c], and SourceForge [P*Sla15] also host these software development tools, so a new FLOSS project may use all of these tools without configuration effort. This standard set of software development tools reduce the effort to work on the FLOSS project. Riehle et al. [Rie+09] go even further and state that “software forges are geared toward making it as easy as possible to find a project, understand it, and contribute to it.” – this also summarizes the goal of wikis.

The development tools of a software forge include a VCS repository, typically with access via the web site. GitHub and GitLab include a web-based editor for source code. Per default, users cannot modify code in software repositories other than their own. This does not create a contribution barrier, though: If users try to modify source code in a software repository other than their own, the whole repository is branched and re-created as their own software repository. The

4.1 WikiDE Concept maintainers of the original project can merge modifications in branches back into the original project. This enables Code Reviews before merging the modifications back. They do not fulfill the requirement Immediate Feedback, though.

Table 4.1 also lists a desktop toolset for comparison, referring to a traditional development toolset consisting of a desktop IDE, a VCS, and an issue tracker. The desktop IDE fulfills the requirements of a Code Editor and with their integrated debuggers, also the requirement of Immediate Feedback. The VCS satisfies the requirement of Version Control per definition. The issue tracker fulfills the requirement of Code Reviews. Depending on the language and the IDE, compatibility to other IDEs is also possible, although this may require an additional overhead to store the application metadata in multiple formats for multiple IDEs. A desktop IDE is not a wiki, though, and requires installation of tools and downloading the application’s source code.

As shown in Table 4.1, no system currently provides a solution on how to integrate Code Reviewsinto a wiki system. Using the method for Code Reviews from the desktop toolset or via GitHub prevents Immediate Feedback in a wiki and is therefore no solution.