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 Context The adoption of Open Source Software (OSS) in Public Sector Organizations (PSOs) is on the rise, driven by benefits such as enhanced interoperability and transparency. However, PSOs encounter challenges stemming from limited technical capabilities and regulatory constraints in public procurement. Objective This study, based on a registered report, explores the organizational aspects of development in public sector OSS projects, i.e., projects initiated, developed, and governed by PSOs. We conjecture that the development diverges significantly from the commonly adopted bazaar model, wherein development is carried out collaboratively within a broader community. Method A purposefully sampled set of six public sector OSS projects was investigated using mixed-methods and compared with previously reported cases of bazaar OSS projects. Results Among the cases, we note that most (80%) of development efforts typically involve a small group of developers (<15) and rely on formalised processes. Developers are commonly procured from national and local service suppliers. Projects are planned top-down by involved PSOs with funding and contributions to development enabled through centralized or decentralized sponsorship. Projects with a centralized sponsorship have one or a few main PSOs funding the major part of the development. Decentralized sponsorship implies multiple PSOs being mutually dependent on each other to pool the necessary resources for the development. All OSS are reported as being of high quality despite limited size and contributions from their communities. Conclusions Findings suggest that public sector OSS projects deviate from the typical bazaar model, highlighting the need for tailored approaches to address challenges and solutions specific to their context.

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.

Abstract Effort estimation models are a fundamental tool in software management, and used as a forecast for resources, constraints and costs associated to software development. For Free/Open Source Software (FOSS) projects, effort estimation is especially complex: professional developers work alongside occasional, volunteer developers, so the overall effort (in person-months) becomes non-trivial to determine. The objective of this work it to develop a simple effort estimation model for FOSS projects, based on the historic data of developers’ effort. The model is fed with direct developer feedback to ensure its accuracy. After extracting the personal development profiles of several thousands of developers from 6 large FOSS projects, we asked them to fill in a questionnaire to determine if they should be considered as full-time developers in the project that they work in. Their feedback was used to fine-tune the value of an effort threshold, above which developers can be considered as full-time. With the help of the over 1,000 questionnaires received, we were able to determine, for every project in our sample, the threshold of commits that separates full-time from non-full-time developers. We finally offer guidelines and a tool to apply our model to FOSS projects that use a version control system.

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.

Lock-in, interoperability, and long-term maintenance are three fundamental challenges that need to be addressed by any organisation involved in development, use and procurement of IT systems. This paper clarifies fundamental concepts and key dimensions of openness and provides examples of work-practices and recommendations for achieving sustainable digitalisation through addressing the fundamental challenges. Specifically, there are three main contributions. First, the concepts open standard, open source software, and open content are clarified and elaborated. Second, the associated three dimensions standard, software, and content are elaborated through examples of how different combinations along the dimensions can enable and inhibit sustainable digitalisation when IT-systems are developed and procured. Third, work-practices used by public sector organisations in specific projects for development and procurement of IT-systems are elaborated with the view to discuss how the three fundamental challenges are being addressed and provide guidance for how organisations can achieve a sustainable digitalisation.

Open source software (OSS) projects are provided under different open source licenses and some projects use other conditions (in addition to licensing terms) for contributors to adhere to. Licensing terms and conditions may affect community involvement and contributions, and are perceived differently by different stakeholders in different OSS projects. The study reports from an exploratory analysis of licensing terms and other conditions for 200 widely used OSS projects, and an investigation of the relationship between licensing terms and other conditions for contributing. We find that strong copyleft licenses are most common and are used in the majority of the projects. Further, a clear majority of the OSS projects use no specific other condition for contributing in addition to the license terms. However, a clear majority of the OSS projects supported by foundations use other conditions for contributing in addition to the license terms. Finally, use of no specific other conditions in addition to the license terms is more common for projects using strong copyleft licensing compared to projects using non-copyleft licensing.

It is widely acknowledged that standards implemented in open source software can reduce risks for lock-in, improve interoperability, and promote competition on the market. However, there is limited knowledge concerning the relationship between standards and their implementations in open source software. This paper reports from an investigation of organisational influences in software standards and open source software implementations of software standards. The study focuses on the RDFa standard and its implementation in the Drupal project. The overarching goal of the study is to establish organisational influences in software standards and their implementations in open source software. More specifically, our objective is to establish organisational influences in the RDFa standard and its implementation in the Drupal project. By conduct of a case study of the RDFa standard and its implementation in the Drupal project we investigate organisational influences in software standards and their implementations in open source software. Specifically, the case study involved quantitative analyses of issue tracker data for different issue trackers for W3C RDFa and the Drupal implementation of RDFa. The case study provides details on how and to what extent organisational influences occur in W3C RDFa and the Drupal implementation of RDFa, by specifically providing a characterisation of issues and results concerning contribution to issue raising and commenting, organisational involvement over time, and individual and organisational collaboration on issues. We find that widely deployed standards can benefit from contributions provided by a range of different individuals, organisations, and types of organisations either directly to a standardisation project or indirectly via an open source project implementing the standard. Further, we also find that open processes for standardisation adopted by W3C may also contribute to open source projects implementing specific standards.

It is widely acknowledged that standards implemented in open source software can reduce the risk for lock-in, improve interoperability, and promote competition on the market. However, there is limited knowledge concerning the relationship between standards and their implementations in open source software. This paper reports from an investigation of influences between software standards and open source software implementations of software standards. The study focuses on the RDFa standard and its implementation in the Drupal project. Specifically, issues in the W3C issue trackers for RDFa and the Drupal issue tracker for RDFa have been analysed. Findings show that there is clear evidence of reciprocal action between RDFa and its implementation in Drupal. The study contributes novel insights concerning effective processes for development and long-term maintenance of software standards and their implementations in open source projects.

Many organisations are dependent upon long-term sustainable software systems and associated communities. In this paper we consider long-term sustainability of Open Source software communities in Open Source software projects involving a fork. There is currently a lack of studies in the literature that address how specific Open Source software communities are affected by a fork. We report from a study aiming to investigate the developer community around the LibreOffice project, which is a fork from the OpenOffice.org project. In so doing, our analysis also covers the OpenOffice.org project and the related Apache OpenOffice project. The results strongly suggest a long-term sustainable LibreOffice community and that there are no signs of stagnation in the LibreOffice project 33 months after the fork. Our analysis provides details on developer communities for the LibreOffice and Apache OpenOffice projects and specifically concerning how they have evolved from the OpenOffice.org community with respect to project activity, developer commitment, and retention of committers over time. Further, we present results from an analysis of first hand experiences from contributors in the LibreOffice community. Findings from our analysis show that Open Source software communities can outlive Open Source software projects and that LibreOffice is perceived by its community as supportive, diversified, and independent. The study contributes new insights concerning challenges related to long-term sustainability of Open Source software communities.

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.

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.

Presents the introductory welcome message from the conference proceedings.

Provides a listing of current committee members and society officers.

Many product development companies are seeking to remain competitive by reconsidering their development strategies, realising the importance of focusing effort on software innovation. Open Source Software is seen by an increasing number of people as a feasible approach to utilising valuable commodity software development and maintenance, allowing them to concentrating on differentiated software. However, such a change presents new challenges. This paper proposes a three-level approach to preparing a company for leveraging the advantages of Open Source Software. The proposal is motivated through a case study in a company which could be seen as an exemplar of the current state of the art in Open Source adoption in complex domains.

Embedded industries have invested a lot in the introduction of software product lines in their software development. In addition, using open source software appears to be a profitable way to obtain good software. This is also applicable for organizations doing product line engineering. On the other hand, because of the diverse use of open source software, product line development is an attractive way of working in open source communities. In fact, the configuration mechanisms used in open source communities may be applicable within software product lines as well. In addition, product line organizations are usually involved in distributed development, which works very efficiently within open source communities. However, at present, there is limited interaction between the open source and product line development communities. Our aim is to explore what the two communities can learn from each other and to develop a better understanding of how the two communities can benefit from each other.

Distributed development (DD) of software systems is an issue of increasing significance for organisations today, all the more so given the current trend towards globalisation. In this paper we present a reference model which can be used as a reference point for any company wishing to review their own DD scenario. This is particularised in two forms, one as an exemplar model for a global (GSD) development scenario and one as a particularisation of this for intra-national DD scenarios. By drawing from eight case-studies on DD, we present ten general strategies for successful DD together with our reference model which characterises an ideal DD situation.

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.

In this paper we discuss the difficulties of designing and running a final year project course for computer science and information systems students. In particular, we present the design of a research-oriented final year project course, where the aim is to develop the student's critical thinking and research skills. We also discuss the lessons learnt during the seven years that the course has been given.