Context: IoT standards are vital for interoperability and longevity, with Open Source Software (OSS) implementations preventing vendor lock-in. These implementations form vast software ecosystems on platforms like GitHub, where industrial participation is crucial. Goal: This study characterizes industrial involvement (participation, leadership, collaboration) across the software ecosystems of four IoT standards (LwM2M, NB-IoT, CoAP, Zigbee) from different standards-setting organizations. It also investigates how software licensing, particularly OSS licenses, reflects and shapes this involvement. Method: We analyzed software projects related to these standards that are publicly available on the GitHub platform, examining authorship of commits, bug reports, pull requests, and metadata like licenses. We identified organizational affiliations (corporate or academic) of contributors to assess their presence and leadership. We performed a licensing analysis to understand the legal frameworks governing these projects. Results: Our research shows significant diversity in ecosystem scale and activity, with a consistent pattern of major corporate and organizational leadership in highly active projects. Despite robust institutional involvement, a pervasive issue is the widespread absence of explicit software licenses, even in collaborative and active repositories. When licenses are present, permissive OSS licenses (e.g., Apache-2.0, MIT) dominate. This indicates a complex and often ambiguous legal landscape. Conclusion: IoT standard ecosystem growth is driven by established organizations. Addressing the prevalent lack of licensing is crucial for fostering clearer collaboration, mitigating legal risks, and ensuring long-term sustainability and adoption of these foundational technologies.

Abstract 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.

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.

No abstract available.

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.

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.

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.

Current techniques for modeling software architecture do not provide sufficient support for modeling architectural design rules. This is a problem in the context of model-driven development in which it is assumed that major design artifacts are represented as formal or semi-formal models. This article addresses this problem by presenting an approach to modeling architectural design rules in UML at the abstraction level of the meaning of the rules. The high abstraction level and the use of UML makes the rules both amenable to automation and easy to understand for both architects and developers, which is crucial to deployment in an organization. To provide a proof-of-concept, a tool was developed that validates a system model against the architectural rules in a separate UML model. To demonstrate the feasibility of the approach, the architectural design rules of an existing live industrial-strength system were modeled according to the approach.

Current techniques for modeling software architecture lacks support for the modeling of architectural design rules, i.e. rules defined by the architect that have to be followed in the detailed design. This is a problem in the context of Model-Driven Development in which it is assumed that major design artifacts are represented as formal or semi-formal models. The PhD project presented in this paper addresses this problem by the definition of a method for modeling architectural design rules in a form that is easily interpreted by developers. A tool for automatic validation of the design model against the architectural rules has also been developed. The method is designed to be easy to learn and use for both architects and developers. As a part of the PhD project the method is also currently validated in a case study on an industrial development project.

A basic premise of model driven development (MDD) is to capture all important design information in a set of formal or semi-formal models which are then automatically kept consistent by tools. The concept however is still relatively immature and there is little by way of empirically validated guidelines. In this paper we report on the use of MDD on a significant real-world project over several years. Our research found the MDD approach to be deficient in terms of modelling architectural design rules. Furthermore, the current body of literature does not offer a satisfactory solution as to how architectural design rules should be modelled. As a result developers have to rely on time-consuming and error-prone manual practices to keep a system consistent with its architecture. To realise the full benefits of MDD it is important to find ways of formalizing architectural design rules which then allow automatic enforcement of the architecture on the system model. Without this, architectural enforcement will remain a bottleneck in large MDD projects.

XMI is a standardized format for model interchange between tools. However, XMI-based interchange currently has one great disadvantage: an XMI file exported from one tool is unlikely to import correctly into a different tool. This makes XMI unusable for moving models around in a heterogeneous development environment, leading to increased maintenance problems. We suggest using specialized XSLT transformations to bridge between the XMI dialects of tools, and report on an industrial case study in which the technique has been successfully applied.

Model driven development has several advantages over traditional development, including simplified maintenance. We demonstrate an architecture which, through model driven engineering, allows heterogeneous distributed development of components in a mechatronics application. Key to the approach is an architecture which allows automated and dynamic component integration, together with model sharing through the transformation of XMI files.