Based on our study of the existing OSS navigators (Section 8.1) and on the results from the OSS developers’ surveys (Section 8.3), to reflect the stimuli (Chapter 6) in the NOSE widgets, the following design decisions were made:
Internal stimuli
Generation change: Generation change is related to the significant restructuring in
the community core. The change is triggered, when several central members leave the community. Hereby, a network graph representation of the project’s social structure offers a good overview. To visualize the network evolution, for each year or for each period between two releases an Social Network (SN) is constructed. The core members within the generated SNs are highlighted using color coding. Another feature to ease the navigation within the SN is the search function. It allows one to search for a certain person within an SN and investigate evolution of his/her neighborhood in more detail.
Changes of organizational principles: To reflect the co-evolution of the system
development and project community, evolution of the normalized number of commits in revision control system (RCS) vs. evolution of the normalized number of emails in project mailing lists are displayed in one widget chart.
Core/Periphery proportion: Besides network representation for OSS communities,
a separate NOSE widget displays the development of the Core/Periphery proportion over time.
Code restructuring: The significant code restructuring is implicitly visualized by
the number of commits. The reaction of community to changes is reflected by the development of community mood. Community mood is measured by the proportion of positive messages to the total number of messages within the project mailing lists and is displayed in the same widget. Nevertheless, the community members need to be informed in advance about significant changes and their advantages. So far, explicit notification within the NOSE dashboard have not been planned.
Quality of infrastructure: In one widget we visualize both the number of new
mails in the project mailing lists and the outflow number. This visualization is used as an approximate reflector for quality and stability of the project infrastructure.
External stimuli
Project domain: Attention increase or decrease to the project domain due to some
external events is reflected in inflow/outflow numbers of project participants over the years. The information is presented in a separate widget.
Similar projects: To reflect the interference between similar (in terms of goal and
domain) OSS projects, our approach is to display the evolution of those projects within the same dashboard. Thereby, the dashboard design is enhanced by a mechanism to switch between projects easily. The NOSE design for all related projects is the same, thus facilitating an intuitive comparison of the projects.
Implementation Details One of the main requirements for the NOSE implemen-
tation was the system availability through the Web. In such a way, OSS developers can easily access the platform without any extra effort of installing additional software. The NOSE system is composed of three components.
Front-end The NOSE front-end was built with well-known Web technologies:
HTML, CSS, and javascript. The dashboard is designed in such a way that it always fills out the whole screen, fulfilling one of the main criteria of dashboards. The NOSE front-end offers the following functionalities to the users:
• Select a project for navigation
• Define what kind of statistics should be displayed in a selected widget • Enlarge a widget by clicking on the magnifier button
• Define a time period when data in the chart should be presented
The widget with a social network graph displays the connections between OSS community members, thus visualizing the social structure of the community. The created graph is based on the entries in the projects mailing list. For each unique mail sender or mail recipient in the project mailing list a new node is created. An edge is created between two members when both members have sent each other mails in the same thread of a project mailing list. The notification emails and threads are filtered from the data. A pair of nodes is only connected by a single undirected edge. Two additional functionalities are provided by the network graph widget:
• Select between release-based and year-based view (cf. Section 5.4),
• Search for a certain person in the graph. If the person is detected, only his/her direct neighborhood is displayed.
Middleware Tomcat 78 is used as the application server between the dashboard
and the back-end. The business logic located on the application server is mainly used to generate or to modify the social network graph. Thus, the web-dashboard consists of a relatively lightweight front-end and at the same time powerful server side. The modifications performed on the server side are simply pushed to the front-end where they get rendered by a browser.
Back-end The LAS-service noseservice handles access to the data stored in
a database (cf. Figure 8.8). The service initiates connection and processes the queries to the database. The results are then parsed into a JSON string and sent back to the Tomcat application server. Additionally, the noseservice stores and manages the users personal preferences concerning the dashboard. Thus, a user can switch between projects without a need to reconfigure the dashboard every time. This allows an intuitive comparison of different projects at first sight.
Architecture Overview Figure 8.9 presents the architecture of the NOSE system.
LAS and the developed noseservice are used in the back-end to get access to the data. The data from the back-end is sent to the Tomcat application server. On the application server, the data is then filtered and an SN is created for the social network graph widget. Alternatively, the data is directly sent to the front-end. In the front-end, the data for a chart is converted into a Google DataTable9 format and then the chart is drawn.
To evaluate and improve our SM/SR concept, it is necessary to test the NOSE dashboard within OSS communities.
8
Tomcat, http://tomcat.apache.org/, last checked 2014/03/17 9
Google DataTable, https://developers.google.com/chart/interactive/docs/reference# DataTable/, last checked 2014/03/17
Figure 8.8: Noseservice in LAS.
LAS
The data is queried using the noseservice
TomCat 7 as application server
HTML and JavaScript Frontend User interface and executes smaller
modifications to charts
Check user actions & modify the network graph Chart data in JSON form.
User configuration
Request log in and user configuration
Request chart data Request chart
Return chart data
Figure 8.9: Simplified Architecture of NOSE.