Reproducible builds (R-Bs) are software engineering practices that reliably create bit-for-bit identical binary executable files from specified source code. R-Bs are applied in some open source software (OSS) projects and distributions to allow verification that the distributed binary has been built from the released source code. The use of R-Bs has been advocated in software maintenance and R-Bs are applied in the development of some OSS security applications. Nonetheless, industry application of R-Bs appears limited, and we seek to understand whether awareness is low or if significant technical and business reasons prevent wider adoption. Through interviews with software practitioners and business managers, this study explores the utility of applying R-Bs in businesses in the primary and secondary software sectors and the business and technical reasons supporting their adoption. We find businesses use R-Bs in the safety-critical and security domains, and R-Bs are valuable for traceability and support collaborative software development. We also found that R-Bs are valued as engineering processes and are seen as a badge of software quality, but without a tangible value proposition. There are good engineering reasons to use R-Bs in industrial software development, and the principle of establishing correspondence between source code and binary offers opportunities for the development of further applications.

Many companies seek to engage with open source software (OSS) projects. Based on insights and experience from practice, we present seven strategies for organizations to leverage long-term involvement with OSS projects.

Open hardware and open source software platforms bring benefits to both implementers and users in the form of system adaptability and maintainability, and through the avoidance of lock-in, for example. Development of the RISC-V Instruction Set Architecture and processors during the last ten years has made the implementation of a desktop computer using open hardware, including open processors, and open source software an approaching possibility. We use the SiFive Unmatched development board and Ubuntu Linux, and the recorded experiences of system builders using the Unmatched board to explore the extent to which it is possible to create an open desktop computer. The work identifies current limitations to implementing an open computer system, which lie mainly at the interface between the operating system and hardware components. Potential solutions to the challenges uncovered are proposed, including greater consideration of openness during the early stages of product design. A further contribution is made by an account of the synergies arising from open collaboration in a private-collective innovation process.

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. (c) 2021 The Authors. Published by Elsevier Inc. This is an open access article under the CC BY license (http://creativecommons.org/licenses/by/4.0/).

ACM Reference Format: Jonas Gamalielsson, Björn Lundell, Simon Butler, Christoffer Brax, Tomas Persson, Anders Mattsson, Tomas Gustavsson, Jonas Feist, and Jonas Öberg. 2022. On Engagement with Open Source Software, Open Source Hardware, and Standard Setting: The Case of White Rabbit. In The 18th International Symposium on Open Collaboration (OpenSym 2022), September 7–9, 2022, Madrid, Spain. ACM, New York, NY, USA, 2 pages. https: //doi.org/10.1145/3555051.3555072

Web analytics technologies provide opportunities for organisations to obtain information about users visiting their websites in order to understand and optimise web usage. Use of such technologies often leads to issues related to data privacy and potential lock-in to specific suppliers and proprietary technologies. Use of open source software (OSS) for web analytics can create conditions for avoiding issues related to data privacy and lock-in, and thereby provides opportunities for a long-term sustainable solution for organisations both in the public and private sectors. The paper characterises use of and engagement with OSS projects for web analytics. Specifically, we contribute a characterisation of use of OSS licensed web analytics technologies in Swedish government authorities, and a characterisation of organisational engagement with the Matomo OSS project for web analytics.

Formulation of mandatory requirements in procurement projects has significant influence on opportunities for development and deployment of Open Source Software (OSS). The paper contributes insights on a widespread practice amongst public procurement projects which causes problematic lock-in effects and thereby inhibits opportunities for use of OSS solutions. Through a systematic investigation of 30 randomly selected procurement projects in the software domain the paper highlights illustrative examples of mandatory requirements which cause lock-in and presents five recommendations for how requirements instead should be formulated in order to avoid causing lock-in. Findings show significant lock-in caused by current procurement practices with a stark preference for proprietary software and SaaS solutions amongst procuring organisations.

The majority of contributions to community open source software (OSS) projects are made by practitioners acting on behalf of companies and other organisations. Previous research has addressed the motivations of both individuals and companies to engage with OSS projects. However, limited research has been undertaken that examines and explains the practical mechanisms or work practices used by companies and their developers to pursue their commercial and technical objectives when engaging with OSS projects. This research investigates the variety of work practices used in public communication channels by company contributors to engage with and contribute to eight community OSS projects. Through interviews with contributors to the eight projects we draw on their experiences and insights to explore the motivations to use particular methods of contribution. We find that companies utilise work practices for contributing to community projects which are congruent with the circumstances and their capabilities that support their short- and long-term needs. We also find that companies contribute to community OSS projects in ways that may not always be apparent from public sources, such as employing core project developers, making donations, and joining project steering committees in order to advance strategic interests. The factors influencing contributor work practices can be complex and are often dynamic arising from considerations such as company and project structure, as well as technical concerns and commercial strategies. The business context in which software created by the OSS project is deployed is also found to influence contributor work practices.

• Analysis of two years’ of community OSS project activity related to interoperability. • Scrutinises challenges of implementing PDF specifications and standards. • Identifies four decision types related to PDF software interoperability. • Software development is largely motivated by need to emulate dominant implementations. • Technical decisions are mediated by considerations of project sustainability. Software interoperability is commonly achieved through the implementation of standards for communication protocols or data representation formats. Standards documents are often complex, difficult to interpret, and may contain errors and inconsistencies, which can lead to differing interpretations and implementations that inhibit interoperability. Through a case study of two years of activity in the Apache PDFBox project we examine day-to-day decisions made concerning implementation of the PDF specifications and standards in a community open source software (OSS) project. Thematic analysis is used to identify semantic themes describing the context of observed decisions concerning interoperability. Fundamental decision types are identified including emulation of the behaviour of dominant implementations and the extent to which to implement the PDF standards. Many factors influencing the decisions are related to the sustainability of the project itself, while other influences result from decisions made by external actors, including the developers of dependencies of PDFBox. This article contributes a fine grained perspective of decision-making about software interoperability by contributors to a community OSS project. The study identifies how decisions made support the continuing technical relevance of the software, and factors that motivate and constrain project activity.

Software interoperability is commonly achieved through the implementation of standards for communication protocols or data representation formats. Standards documents are often complex, difficult to interpret, and may contain errors and inconsistencies, which can lead to differing interpretations and implementations that inhibit interoperability. Through a case study of two years of activity in the Apache PDFBox project we examine day-to-day decisions made concerning implementation of the PDF specifications and standards in a community open source software (OSS) project. Thematic analysis is used to identify semantic themes describing the context of observed decisions concerning interoperability. Fundamental decision types are identified including emulation of the behaviour of dominant implementations and the extent to which to implement the PDF standards. Many factors influencing the decisions are related to the sustainability of the project itself, while other influences result from decisions made by external actors, including the developers of dependencies of PDFBox. This article contributes a fine grained perspective of decision-making about software interoperability by contributors to a community OSS project. The study identifies how decisions made support the continuing technical relevance of the software, and factors that motivate and constrain project activity. (C) 2019 The Authors. Published by Elsevier Inc. This is an open access article under the CC BY license. (http://creativecommons.org/licenses/by/4.0/)

Professionals contribute to open source software (OSS) projects as part of their employment. Previous research has addressed motivations of individuals and the ways they engage with OSS projects. However, there is a lack of research which examines and explains work practices used by companies in their engagement: with projects. Work practices used by companies to contribute to five established OSS projects are investigated through examination of the actions of employees in public communication channels and draw on our experiences when analysing engagement with the same projects. We find that companies utilise work practices for contributing which are congruent with the circumstances and their capabilities that support their short and long term needs. We find that companies contribute to OSS projects indifferent ways, such as employing core project developers, making donations, and joining project steering committees in order to advance strategic interests.

For helping us deliver timely decisions to our authors, the Editors-in-Chief and Publisher would like to thank the following individuals that contributed reviews between November 1, 2015 and November 1, 2016. We applaud your efforts and dedication to the community.

Identifier names are the principal means of recording and communicating ideas in source code and are a significant source of information for software developers and maintainers, and the tools that support their work. This research aims to increase understanding of identifier name content types - words, abbreviations, etc. - and phrasal structures - noun phrases, verb phrases, etc. - by improving techniques for the analysis of identifier names. The techniques and knowledge acquired can be applied to improve program comprehension tools that support internal code quality, concept location, traceability and model extraction. Previous detailed investigations of identifier names have focused on method names, and the content and structure of Java class and reference (field, parameter, and variable) names are less well understood. I developed improved algorithms to tokenise names, and trained part-of-speech tagger models on identifier names to support the analysis of class and reference names in a corpus of 60 open source Java projects. I confirm that developers structure the majority of names according to identifier naming conventions, and use phrasal structures reported in the literature. I also show that developers use a wider variety of content types and phrasal structures than previously understood. Unusually structured class names are largely project-specific naming conventions, but could indicate design issues. Analysis of phrasal reference names showed that developers most often use the phrasal structures described in the literature and used to support the extraction of information from names, but also choose unexpected phrasal structures, and complex, multi-phrasal, names. Using Nominal - software I created to evaluate adherence to naming conventions - I found developers tend to follow naming conventions, but that adherence to published conventions varies between projects because developers also establish new conventions for the use of typography, content types and phrasal structure to support their work: particularly to distinguish the roles of Java field names.

Class names represent the concepts implemented in object-oriented source code and are key elements in program comprehension and, thus, software maintenance. Programming conventions often state that class names should be noun-phrases, but there is little further guidance for developers on the composition of class names. Other researchers have observed that the majority of Java class identifier names are composed of one or more nouns preceded, optionally, by one or more adjectives. However, no detailed analysis of class identifier name structure has been undertaken that could be leveraged to support program comprehension activities. We investigate the lexical and syntactic composition of Java class identifier names in two ways. Firstly, as others have done for C function and Java method names, we identify conventional patterns found in the use of parts of speech. Secondly, we identify the origin of words used in class names within the name of any super class and implemented interfaces to identify patterns of class name construction related to inheritance. Through the analysis of 120,000 unique class names found in 60 open source projects we identify both common and project specific class naming conventions. We apply this knowledge in a case study of the mind-mapping tool Freemind to investigate whether class names that follow unconventional naming schemes are candidates for refactoring – either a name refactoring that conforms to established naming conventions within the code base, or refactoring of the class that results in conventionally named classes. Keywords-Java class naming; identifier names;

Naming conventions can help the readability and comprehension of code, and thus the onboarding of new developers. Conventions also provide cues that help developers and tools extract information from identifier names to support software maintenance. Tools exist to automatically check naming conventions but they are often limited to simple checks, e.g. regarding typography. The adherence to more elaborate conventions, such as the use of noun and verbal phrases in names, is not checked. We present Nominal, a naming convention checking library for Java that allows the declarative specification of conventions regarding typography and the use of abbreviations and phrases. To test Nominal, and to investigate the extent to which developers follow conventions, we extract 3.5 million reference - field, formal argument and local variable - name declarations from 60 FLOSS projects and determine their adherence to two well-known Java naming convention guidelines that give developers scope to choose a variety of forms of name, and sometimes offer conflicting advice. We found developers largely follow naming conventions, but adherence to specific conventions varies widely.

Identifier names are the principal means of recording and communicating ideas in source code and are a significant source of information for software developers and maintainers, and the tools that support their work. This research aims to increase understanding of identifier name content types - words, abbreviations, etc. - and phrasal structures - noun phrases, verb phrases, etc. - by improving techniques for the analysis of identifier names. The techniques and knowledge acquired can be applied to improve program comprehension tools that support internal code quality, concept location, traceability and model extraction. Previous detailed investigations of identifier names have focused on method names, and the content and structure of Java class and reference (field, parameter, and variable) names are less well understood. I developed improved algorithms to tokenise names, and trained part-of-speech tagger models on identifier names to support the analysis of class and reference names in a corpus of 60 open source Java projects. I confirm that developers structure the majority of names according to identifier naming conventions, and use phrasal structures reported in the literature. I also show that developers use a wider variety of content types and phrasal structures than previously understood. Unusually structured class names are largely project-specific naming conventions, but could indicate design issues. Analysis of phrasal reference names showed that developers most often use the phrasal structures described in the literature and used to support the extraction of information from names, but also choose unexpected phrasal structures, and complex, multi-phrasal, names. Using Nominal - software I created to evaluate adherence to naming conventions - I found developers tend to follow naming conventions, but that adherence to published conventions varies between projects because developers also establish new conventions for the use of typography, content types and phrasal structure to support their work: particularly to distinguish the roles of Java field names.

The readability of identifiers is a major factor of program comprehension and an aim of naming convention guidelines. Due to their semantic content, identifiers are also used in feature and bug location, among other software maintenance tasks. Looking at how names are used in practice may lead to insights on potential problems for comprehension and for programming support tools that process identifiers. Class and method names are already well represented in the literature. This paper presents an investigation of Java field, formal argument and local variable names, which we collectively call reference names. These names cannot be ignored because they constitute over half the unique names and almost 70% of the name declarations in the corpus investigated. We analysed the forms of 3.5 million reference name declarations in 60 well known Java projects, examining the phrasal structure of names composed of known words and acronyms. The structures found in practice were evaluated against those given in the literature. The use of unknown abbreviations and words, which may pose a problem for program comprehension, was also identified. Based on our observations of the rich diversity of reference names, we suggest issues to be taken into account for future academic research and for improving tools that rely on names as sources of information.

Naming conventions can help the readability and comprehension of code, and thus the onboarding of new developers. Conventions also provide cues that help developers and tools extract information from identifier names to support software maintenance. Tools exist to automatically check naming conventions but they are often limited to simple checks, e.g. regarding typography. The adherence to more elaborate conventions, such as the use of noun and verbal phrases in names, is not checked. We present NOMINAL, a naming convention checking library for Java that allows the declarative specification of conventions regarding typography and the use of abbreviations and phrases. To test NOMINAL, and to investigate the extent to which developers follow conventions, we extract 3.5 million reference — field, formal argument and local variable — name declarations from 60 FLOSS projects and determine their adherence to two wellknown Java naming convention guidelines that give developers scope to choose a variety of forms of name, and sometimes offer conflicting advice. We found developers largely follow naming conventions, but adherence to specific conventions varies widely.

INVocD is a database of the identifier name declarations and vocabulary found in 60 FLOSS Java projects where the source code structure is recorded and the identifier name vocabulary is made directly available, offering advantages for identifier name research over conventional source code models. The database has been used to support a range of research projects from identifier name analysis to concept location, and provides many opportunities to researchers. INVocD may be downloaded from http://oro.open.ac.uk/36992.

Classes represent key elements of knowledge in object-orientated source code. Class identifier names describe the knowledge recorded in the class and, much of the time, record some detail of the lineage of the class. We investigate the structure of Java class names identifying common patterns of naming and the way components of class identifier names are repeated in inheritance hierarchies. Detailed knowledge of class identifier name structures can be used to improve the accuracy of concept location tools, to support reverse engineering of domain models and requirements traceability, and to support development teams through class identifier naming recommendation systems.