Web accessibility and open source software

A Web browser provides a uniform user interface to different types of information. Making this interface universally accessible and more interactive is a long term goal still far from being achieved. Universally accessible browsers require novel interaction modalities and additional functionalities, for which existing browsers tend to provide only partial solutions. Although functionality for Web accessibility can be found as open source and free software components, their reuse and integration is complex because they were developed in diverse implementation environments, following standards and conventions incompatible with the Web. To enable the integration of existing partial solutions within a mainstream Web browser environment, we have developed a middleware infrastructure, AMICO:WEB. This enables browser access to a wide variety of open source and free software components. The main contribution of AMICO:WEB is in enabling the syntactic interoperability between Web extension mechanisms and a variety of integration mechanisms used by open source and free software components. It also bridges the semantic differences between the high-level world of Web XML-based APIs and the low-level APIs of the device-oriented world. We discuss the design decisions made during the development of AMICO:WEB in the context of Web accessibility, using two typical usage scenarios: one describing a disabled user using a mainstream Web browser with additional interaction modalities; another describing a non-disabled user browsing in a suboptimal interaction situation.

Chinese software companies are increasingly using open source software (OSS) components in software development. Development with OSS components faces challenges with respect to component selection, component integration, licensing compliance, and system maintenance. Although these issues have been investigated in the industry in other countries, few similar studies have been performed in China. It is therefore difficult for Chinese software companies to be aware of their special issues and to make the necessary improvements. This article describes a questionnaire‐based survey of software development with OSS components in Chinese software companies. Data from 47 completed development projects in 43 companies were collected. The results show that the main motivation behind using OSS components was their modifiability and low license cost. Using a web search engine was the most common method of locating OSS components. Local acquaintance and compliance requirements were the major decisive factors in choosing a suitable component. To avoid legal exposure, the common strategy was to use components without licensing constraints. The major cost of OSS‐based projects was the cost to learn and understand OSS components. Almost 84% of the components needed bug fixing or other changes to the code. However, close participation with the OSS community was rare. Copyright © 2008 John Wiley & Sons, Ltd.

Chinese software companies are increasingly using Open Source Software (OSS) components in system development. Integrating such components into new software systems leads to challenges related to component selection, component integration and testing, licensing compliance, and system maintenance. Although these issues have been investigated industrially in other countries, few state-of-the-practice studies have so far been performed in China and with a representative subset of software companies. It is therefore difficult for Chinese software companies to be aware of special issues, or to plan improvement of OSS-related processes. This paper describes a questionnaire-based survey in Chinese software companies of software development with existing OSS components. Data from 47 finished development projects in 43 companies have been collected. The results show that use of web search engines was the most common method to locate OSS components. Local expertise combined with requirements compliance was the most decisive factors when choosing an identified component. To avoid legal exposure, the common strategy was to use components without licensing constraints. About 84% of the components needed bug fixing or other code changes, rarely relies on support from the OSS community. However, close participation with the OSS community was rare, although most developers meant that this was important.

The increasing number of high quality open source software (OSS) components lets industrial organizations seriously consider integrating them into their software solutions for critical business cases. But thorough considerations have to be undertaken to choose the “right” OSS component for a specific business case. OSS components need to fulfill specific functional and non-functional requirements, must fit into a planned architecture, and must comply with context factors in a specific environment. This chapter introduces a prototyping approach to evaluate OSS components. The prototyping approach provides decision makers with context-specific evaluation results and a prototype for demonstration purposes. The approach can be used by industrial organizations to decide on the feasibility of OSS components in their concrete business cases. We present one of the industrial case studies we conducted in a practical course at the University of Kaiserslautern to demonstrate the application of our approach in practice. This case study shows that even inexperienced developers like students can produce valuable evaluation results for an industrial customer that wants to use open source components.

Component-Based Software Development is a conventional way of working for software-intensive businesses and Open Source Software (OSS) components are frequently considered by businesses for adoption and inclusion in software products. Previous research has found a variety of practices used to support the adoption of OSS components, including formally specified processes and less formal, developer-led approaches, and that the practices used continue to develop. Evolutionary pressures identified include the proliferation of available OSS components and increases in the pace of software development as businesses move towards continuous integration and delivery. We investigate work practices used in six software-intensive businesses in the primary and secondary software sectors to understand current approaches to OSS component adoption and the challenges businesses face establishing effective work practices to evaluate OSS components. We find businesses have established processes for evaluating OSS components and communities that support more complex and nuanced considerations of the cost and risks of component adoption alongside matters such as licence compliance and functional requirements. We also found that the increasing pace and volume of software development within some businesses provides pressure to continue to evolve software evaluation processes.

Software development for the communication networks ‘monitoring is usually based on Open Source software components, as an effective and low cost technological option. However, when we evaluated a product developed with Open Source components, we found that its efficiency is less than other similar Open Source software developed with proprietary tools; which is unusual or at least it isn’t expected. To the best of our knowledge this phenomenon has not been reported in the literature. Hence, our aim was to identify the circumstances that explain why the efficiency of Open Source software applications tends to be less than Open Source applications developed with proprietary software tools. A controlled experiment was performed at Universidad de las Fuerzas Armadas ESPE of Ecuador to compare the performance of two software tools for communication networks’ monitoring. A post hoc analysis reveled that some causal relationships that could explain the unexpected behavior of compared applications’ efficiency. From the statistical perspective, there is no significant difference in effectiveness between Open Source and proprieta- ry applications for communication networks’ monitoring. Efficiency of the Open Source tools depends on a large extent of software components used for their integration, which apparently is not considered in the development of this kind of applications.

Over the last five years, open source software has moved into mainstream areas such as Internet and financial applications, with software such as Linux and Apache Web Server now supporting mission-critical operations. Open source software can offer both cost reductions and improvements in software quality. However, the uptake by incumbent telecommunications providers has been virtually zero, instead focusing on major commercial-off-the-shelf (COTS) packages, due to a mixture of prior strategic investments and perceptions over open source risks. This paper addresses the scope for use of open source software in telecommunications operational support systems (OSS). Firstly, the technical scope for open source software is addressed, covering the maturity of available open source software components, and the ways in which these components can have an impact on OSS software architecture. Secondly, the commercial aspects are presented, covering benefits, commercial models and risks. An OSS life cost comparison of open source versus COTS software is included. Thirdly, a test OSS created by BT using primarily open source software, combined with OSS standards to provide a minimum cost base, is presented and analysed. The paper concludes with a statement on the potential for the use of open source software in OSS, and suggests possible next steps.

Many organizations develop software systems using Open Source Software (OSS) components. OSS components have a high risk of going out of support, making dependency on OSS components risky. So, it is imperative to perform risk assessment during the selection of OSS components. A model that can predict OSS survivability provides an objective criterion for such an assessment. Currently, there are no simple, quick and easy methods to predict survivability of OSS components. In this paper, we build a simple Multi Layer Perceptron (MLP) to predict OSS survivability. We performed experiments on 449 OSS components containing 215 active components and 234 inactive components collected from GitHub. The evaluation results show MLP achieves 81.44% validation accuracy for survivability prediction on GithHub dataset.

When referring to Open Source Software (OSS) components, researchers, coders and managers do not feel comfortable in defining them as COTS. Many discussions have been aimed to decide whether or not OSS can be considered a COTS without reaching the unanimous consensus of the different international communities. This paper abandons any theoretical aspect of that question and focuses on the practical steps to follow when assembling component-based systems using also OSS components. All the activities normally performed when integrating COTS in a in-house built software are reviewed with the intention of underlining if the availability of the source code (and its possible exploitation) makes any difference. Moreover this article analyzes all the activities to perform when using OSS in a component-based system that are not necessary when using COTS. The purpose of this paper is to provide a guideline for the correct use of OSS within component-based systems, and not to answer whether OSS are considered or not COTS, leaving this task to the reader.

Through initiatives such as open sourcing, software development organizations have embraced component reuse. Inner sourcing, in which organizations reuse internally created components, is gaining interest. Large companies such as Philips, PayPal and Ericsson have embraced inner source initiatives. Software components reuse can significantly reduce software development and testing time. A challenge when reusing components is to gauge their quality and projected reliability over time. Minor component changes can create unforeseen complexities. This work proposes STATS - Software Component Trend Analysis Over Time Series, a self-directed artificial neural network which uses historic performances to predict the performance of inner source components over time. Using time series-based learning instances, STATS can aid in the prediction of component trouble reports based on historic knowledge. This is accomplished through the history of components trouble reports over varying time series. Using STATS, system architects and developers predict the reliability of candidate open source and inner source software components in the medium and long term.

The reuse and integration of Open Source Software (OSS) components provided by OSS communities is becoming an economical and strategic need for today’s organizations. The integration of OSS components provides many benefits, but also risks and challenges. One of the most important risks is the lack of effective and timely OSS community support for dealing with possible integration problems. For gaining an understanding of the common problems that organizations face when integrating OSS components, and the role played by OSS communities, we performed an exploratory study on 25 OSS integration projects from different European organizations. The results show that the main way of reducing integration problems was the use of OSS components from well-established communities; therefore very few integration problems were identified. In most of the cases these problems were successfully solved with the support from the OSS community and/or colleagues. In addition, contrary to the common belief that understanding code from someone else is a hard and undesirable task, some integrators consider OSS code even more understandable than their own code.KeywordsOpen Source SoftwareIntegration ProblemIntegrator PerspectiveIntegration IssueOpen Source Software ProjectThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Using OTS (Off-The-Shelf) components in software projects has become increasing popular in the IT industry. After project managers opt for OTS components, they can decide to use COTS (Commercial-Off-The-Shelf) components or OSS (Open Source Software) components instead of building these themselves. This paper describes an empirical study on why project decision-makers use COTS components instead of OSS components, or vice versa. The study was performed in form of an international survey on motivation and risks of using OTS components, conducted in Norway, Italy and Germany. We have currently gathered data on 71 projects using only COTS components and 39 projects using only OSS components, and 5 using both COTS and OSS components. Results show that both COTS and OSS components were used in small, medium and large software houses and IT consulting companies. The overall software system also covers several application domains.Both COTS and OSS were expected to contribute to shorter time-to-market, less development effort and the application of newest technology. However, COTS users believe that COTS component should have good quality, technical support, and will follow the market trend. OSS users care more about the free ownership and openness of the source code. Projects using COTS components had more difficulties in estimating selection effort, following customer requirement changes, and controlling the component’s negative effect on system security. On the other hand, OSS user had more difficulties in getting the support reputation of OSS component providers.KeywordsSource CodeOpen Source SoftwareSoftware ProjectSpecific MotivationIndustrial ProjectThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Comparison of open source maturity models

Enhancing C/C++ based OSS development and discoverability with CBRJS: A Rust/Node.js/WebAssembly framework for repackaging legacy codebases

The success of Component-Based Software Development is based on the ability of an implementer team to select, assemble and integrate third-party and other components with own application software, in order to create a software system that satisfies (most of) the customer/client’s stated needs in an economic and flexible way. Nowadays, the reuse of Open Source Software (OSS) components available from the Internet is playing a strategic role in the industry. This chapter aims at providing empirical evidence on current industrial OSS selection practices based on semi-structured interviews performed in 17 European organizations. In particular, the study tackles the following activities: (1) initial identification of available OSS components, (2) closer evaluation of the identified components, (3) conclusive decision-making of the chosen ones, and (4) updating of OSS-relevant experience and knowledge for the actual company. For simplicity we have omitted system-wide integration and testing activities. The results of this study ought to be valuable not just for researchers, as a sobering basis in their quest for practical selection methods; but also for practitioners that regularly drive OSS selection processes with potential to learn from other colleagues’ work.