ZOOOM case studies: overview, importance, recommendations
What is there to know about ZOOOM case studies?
- Business cases from literature and studies
- ZOOOM case studies
- Motivation of companies to engage with the 3Os
- Challenges and risks
- Role of open technologies in the activities of a company
- The legal aspects
- IP and licence management
- Evolution of businesses based on 3Os
- The role of ecosystems
- Recommendations from the ZOOOM case studies
Business cases from literature and studies
ZOOOM identified several companies that served as case studies for analysing best practices, challenges, and risks relating to the use of the 3Os for business purposes. These companies have been selected through two separate processes: the first category consists of a literature review, which allowed us to single out companies that are often cited across various areas of management and legal studies; in the second category, we navigated the networks of ZOOOM partners, the open web and the social networks (e.g., LinkedIn) to find out about companies based in the EU area whose activities are related to the 3Os.
In the case studies selection process for both categories of cases we paid special attention to those companies related to the four emerging technologies chosen by the ZOOOM project, i.e., AI, Blockchain, Quantum, and Robotics. Although the selection process took into account all the verticals equally, most cases revolve around the use of AI and Blockchain technologies. Quantum and Robotics are unfortunately underrepresented, which is likely owing to the highly innovative character of these technologies in the EU, potentially large orientation towards open hardware, and a delay in the academic literature production relating to such areas.
As for primary data, we conducted in-depth interviews with 25 companies of the second category, investigating aspects such as: the role of open assets in the company’s activities and value creation/capture; the company’s approach to IP management issues; the motivations for the adoption of/contribution to open assets; challenges, risks, and opportunities enabled by the engagement in open technologies; the role of the company in their market and ecosystem.
The following cases were identified as the most relevant from the academic and professional literature reviews, with respect to business and ecosystem aspects relating to the 3Os. The cases have been categorised according to their involvement in the 3Os: free and open source software (OSS), open data (OD), and open hardware (OH).
OS | OD | OH | Case | Source |
OS | OH | Arduino | Blind, Knut et al. (2021) | |
OS | Cendio | Dahlander & Magnusson (2008) | ||
OS | CentOS (Red Hat, Linux) | Blind, Knut et al. (2021) | ||
OS | OH | Embedded Linux | Gruber & Henkel (2006) | |
OD | ESS-CSDL | Runeson et al. (2021) | ||
OD | Temiz et al. (2022) | |||
OD | Temiz et al. (2022) | |||
OS | IBM | Watson et al. (2008) | ||
OD | Jobtech | Runeson et al. (2021) | ||
OS | LibreOffice | Blind, Knut et al. (2021) | ||
OH | Makerbot | Viseur & Jullien (2022) | ||
OS | OH | MyriadRF | Blind, Knut et al. (2021) | |
OS | MySQL | Dahlander & Magnusson (2008); Rajala et al. (2012) | ||
OS | Netscape-Mozilla | Dell’Era et al. (2020) | ||
OS | Nextcloud | Blind, Knut et al. (2021) | ||
OS | OH | Open Compute Project (FB) | Blind, Knut et al. (2021) | |
OS | OpenOSX | Watson et al. (2008) | ||
OS | OpenStack | Teixeira et al. (2015) | ||
OD | OpenStreetMap | Runeson et al. (2021) | ||
OS | OW2 | Blind, Knut et al. (2021) | ||
OH | Prusa | Viseur & Jullien (2022) | ||
OS | RedHat | Dell’Era et al. (2020); Watson et al. (2008) | ||
OH | RepRap | Blind, Knut et al. (2021) | ||
OD | Road Datalab | Runeson et al. (2021) | ||
OS | Roxen | Dahlander & Magnusson (2008) | ||
OH | SiFive (RISC-V) | Blind, Knut et al. (2021) | ||
OS | Software Heritage | Blind, Knut et al. (2021) | ||
OS | SOT | Dahlander & Magnusson (2008) | ||
OH | Sparkfun | Li & Seering (2019); Moritz et al. (2016) | ||
OD | Structural Genomics Consortium | Temiz et al. (2022) | ||
OH | Ultimaker | Moritz et al. (2016); Viseur & Jullien (2022) | ||
OH | WhiteRabbit (CERN) | Blind, Knut et al. (2021) | ||
OS | OD | X-Road | Blind, Knut et al. (2021) | |
OS | Yocto (Red Hat, Linux) | Blind, Knut et al. (2021) |
Companies such as RedHat, SpikeSource, and OpenOSX have been analysed by Watson et al. (2008) to describe the Corporate Distribution model of software production or distribution. Here, similarly to an Open Community model, the development and support of software is volunteered with limited or no commercial interest; however, in the corporate distribution model, firms create and capture value by identifying best-of-breed OSS projects, improving distribution methods for these products, and providing complementary services in order to make these OSS products more accessible to a broader market. Additionally, CentOS, LibreOffice, Nextcloud and OW2 are cases encompassing aspects relating to end user applications in connection with open-source software (Blind et al. 2021).
CentOS and Yocto are projects that enable building customized software platforms for hardware. Firstly, both cases unveil the interlinks of embedded systems to the underlying layers of Red Hat and Linux. Secondly, these cases also demonstrate the possibilities that come when open-source software and open hardware are combined (Blind et al. 2021).
IBM is another case analysed by Watson et al (2008), a high-profile corporation that contributes to developing OSS projects on the Apache’s Web server. IBM embraces the so-called Sponsored Open Source model, where OSS projects are initiated by corporations releasing previously closed codes and encouraging their employees to continue to work on the now open project – Eclipse is an example of an integrated software development environment released as OSS by IBM.
MySQL, Cendio, Roxen, and SOT have been analysed by Dahlander & Magnusson (2008) to describe three means by which firms exploit communities: (1) accessing communities to extend the resource base; (2) aligning firm strategies with the community; and (3) assimilating communities in order to integrate and share results. These cases illustrate how firms found it necessary to change their business models to align with the communities. MySQL needed to build a sufficiently large community and engage actively with the community to create a virtuous development cycle. Cendio used an adaptive approach, and did not try to change the direction of the development in the communities in any substantial way, but instead focused on using what was developed in the communities and integrating this work with internally developed components. Both Roxen and SOT founded a community but then had issues with attracting new members; SOT tried to influence community developments by offering incentives to individuals to work with the community, to enhance both its and the firm’s reputation, and give the firm more scope for controlling the direction of community developments. For community aspects, the cases Yocto and Software Heritage are also of relevance (See Blind, Knut et al. 2021).
Arduino is an example of a success case on OH, and of a maker community that has evolved into viable business and an international benchmark. The design of the hardware is open for commercial and non-commercial purposes and the business value is based on trademark, sale of physical products, consultancy and even SaaS-type of business (Blind et al. 2021).
Makerbot, Prusa, and Ultimaker are compared with each other by Viseur & Jullien (2022), who identified two types of business models in the context of OH: Closed Supply-chain Platform and Open Industry platform.
Makerbot belongs to the first type, which consists of taking control of all the components of a product in order to master its architectures, and therefore favours a closed approach to innovation in order to guarantee the technological consistency of its platform. This involves a razor-blade type business model that relies on the sale of raw materials but requires strong control over the overall quality of the proposed solutions (the assembly of components), and also over the compatibility between the different elements of the hardware. As a result, the community is excluded from hardware developments. This strategy broadly follows the classic pattern identified in the open-source sector, or the more general framework of open innovation, where the community is exploited temporarily at the launch of the activity, to compensate for the lack of resources of the company, with a gradual closure of the development process, because the company is no longer able to capture the value created by the community. The company then develops (contractual) collaborations with suppliers or its own unitary technologies that guarantee it total control over the innovative solutions it proposes.
By contrast, Prusa Research and Ultimaker belong to the second type, embracing a particular form of innovation ambidexterity where the companies have developed their capacities to make both incremental innovation and to explore new offers. Then, Ultimaker has even abandoned the open-hardware strategy, while Prusa’s open-hardware strategy remains important for it to maintain exploratory capacities. The publication of machine specifications under a free license is necessary to generate contributions, but also to allow users to test configurations and thus report bugs. in contrast to the Makerbot’s approach, Open Industry platform strategy does not harm value capture, because the main source of revenue does not come from selling machines to its user-developers, but from printing solutions, for which the company possesses other specific human assets (business experts or experts in 3D technology), which are also expensive to replicate.
Cases White Rabbit (CERN), MyriadRF and RepRap elucidate the role of enabling technologies and Open Compute Project (FB) and SiFive (RISC-V) the role of computing, both within the context of open hardware (Blind et al. 2021).
Facebook (Meta) and Google are examples of companies that have been able to leverage OD to target campaigns with unprecedented precision, especially through a combination of data of different type (Temiz et al. 2022). These are exceptional cases, in the area of OD, due to the difficulty of capturing value from data. Indeed, enterprises face remarkable challenges in order to find, access, and select OD (Enders et al 2021; Kamariotou and Kitsiosis 2022; Krasikov et al. 2020; Monino 2021). For example, the data must not only be open, but also useful, useable, cleaned, and technically and legally accessible, and it must be matched by investments in information, metadata, software, quality management, and social tools that can cultivate the ecosystem around the open data, in addition to data analytics capabilities.
Case OW2 focuses on infrastructure software, case Software Heritage is meant for preserving software source code, case White Rabbit is a fully deterministic Ethernet-based network and case X-Road manages access to sensitive data. All these cases enlighten aspects that relate to open-source software in the public sector and connections of open source software with data (Blind et al. 2021).
Cases ESS-CDL, RoDL and JobTech shed light on emerging open data ecosystems (See Runeson et al. 2021) and open innovation. These cases are compared against the case of OpenStreetMap as a community-driven, truly open data ecosystem. The case studies observes the differences between shared data and open data and highlights the components of open data ecosystems and the need for them to be value-driven.
ZOOOM case studies
The following case studies were studied through interviews. They are categorised in two dimensions: firstly, on the left side, with respect to the form of the open technologies, i.e. 3Os, and secondly, on the rights side, with respect to the area of the emerging technologies, i.e. 4Es.
With regard to 3Os, the cases have been categorized in three categories: 1) free and open source software (OS); 2) open data (OD); 3) open hardware (OH). Regarding the 4Es, the cases have been categorized in four categories: 1) artificial intelligence and machine learning (AI); 2) blockchain (BC), 3) quantum (QN); 4) robotics (RB).
The table also makes a distinction between two central perspectives on the role of the organizations towards the utilization of the technologies:
- User (marked as a grey block): User is an organization providing products or services that utilize open or emerging technologies.
- Maker (marked as a black box): Maker is an organization participating in developing and contributing to open or emerging technologies.
Motivation of companies to engage with the 3Os
In the dynamic landscape of modern business, open technologies have emerged as a powerful force driving competitive advantage, fostering innovation, and shaping the ethos of companies across various industries. Open source software, open hardware, and open data present a unique opportunity for organisations to leverage collaborative development, harness external expertise, and participate in a global community committed to shared progress.
Motivations | Instances |
Strategic and competitive advantages | 18 |
Technological innovation | 7 |
Standardization and compatibility | 6 |
Social and ethical motivations | 6 |
Personal motivations | 3 |
Challenges and risks
All the interviewees agreed that open technologies represent an invaluable resource, providing their companies with a dynamic realm of possibilities. Nonetheless, businesses leveraging the 3Os must navigate a variety of challenges at both legal and economic levels. Drawing on insights from the interviews, this section delves into the multifaceted challenges associated with the use and development of open assets for business purposes, encompassing legal complexities, value capture dynamics, security concerns, customer biases, and community-related considerations.
Challenges and risks | Instances |
Legal complexities | 8 |
Value capture dynamics | 11 |
Security concerns | 5 |
Communicating Open Source | 5 |
Community-related issues | 6 |
Role of open technologies in the activities of a company
The interviews reveal the intricate relationship between openness, proprietary solutions, and innovation in software development. Open assets play a significant role across various companies’ activities, fostering innovation, collaboration and competitive advantage. The companies leverage OSS, OD, and OH to varying degrees in combination with closed elements to create a synergy that drives their business operations. The closed part of the activities may entail additional software, but it can also be other types of intellectual property, like confidential information, trade secrets and know-how, or it may be based on patents, closed infrastructure or computing capacity, or even on layers of capabilities and services.
OSS is a widely recognized and adopted concept in the tech industry, and companies from our cases are actively engaged in OSS communities and projects. It appears, OSS has a more central role compared to OD or OH: it is often highlighted as a key enabler of innovation, collaboration, and differentiation across various companies’ activities. However, OSS-related businesses frequently rely on OD sources to enhance their products and services. This contributes to more accurate analysis, predictions, and decision-making for various sectors such as public transport, manufacturing, pharmaceutics, energy, retail, and finance.
The relationship between OSS related businesses, OD, and OH is intertwined, creating a comprehensive ecosystem of open assets. Our cases suggest that OSS serves as the main source of innovation and value creation in various sectors. The integration of OD and, in our case to a lesser extent also OH, adds depth and breadth to the OSS business landscape.
OSS related companies can play a crucial role in supporting OD and OH initiatives by providing free and open tools, platforms and data that can be used, modified and shared. They collaborate and co-create with OD and OH communities, by contributing to the development and distribution of OD and OH and by engaging in open dialogue and feedback. OSS relates to OD and OH differently in each case. Some use OSS to work with OD or OH, some use it to offer services or solutions, some use it to collaborate or co-create and some use OSS to promote or advocate for openness.
While some companies utilize OSS solely as a tool, others contribute to the open-source community actively. Sector and regional disparities exist and certain companies generate revenue beyond OSS. Notably, cases like OpenStreetMap (OSM) showcase harmonious coexistence in these domains and demonstrate how OSS and other open elements can synergize. OSM uses OSS to collect, edit, and share geospatial data and also promotes OD and OH by making the data available to anyone under an open license.
Monitoring and recognizing interaction between OSS and other open-source domains is essential for companies looking to harness the full potential of open assets and foster a collaborative ecosystem, because it drives continuous innovation and growth. The interlinks between OSS, OD, and also OH are apparent in various dimensions of these companies’ strategies. Whether it is the incorporation of OH components, utilization of OD sources, or the use of OSS platforms, the integration of these elements strengthens the companies’ offerings and enhances their competitive advantage. The various 3Os domains can interact well and complement each other in several ways and across different sectors.
The legal aspects
In the use of an open asset, open platform or database, users have to navigate complex IP issues. Establishing terms and conditions under which software/hardware/data can be accessed and used requires legal and business expertise. Licenses differ significantly in terms of requirements for attribution, redistribution, modification, and compatibility with other licenses. Especially the latter issue (compatibility with other licenses) can be very challenging in practice, as some licenses can be combined in a single project, while others are not compatible and may create conflicts if used together. In addition to this, some open-source licenses have multiple versions (e.g., GPL 2.0, GPL 3.0) with different terms.
Legal complexities manifest themselves especially in two dimensions: how the companies interact with other companies through the licensing terms, and how the company manages its IP and keeps track of the license compatibility internally within the company.
When discussing the type of license used by the companies, some of the companies mentioned open-source systems, frameworks or communities, e.g., Kubernetes, Symfony and Raspberry Pi. This is quite understandable, as these frameworks are formed around technologies with several components that differ from each other. Some of the components may be software, some hardware; some consist of kernels, operating systems and design files; some extend heavily to APIs. As these frameworks consist of different types of technological components, also the licenses involved may be numerous and even difficult to be found.
IP and licence management
Understanding the open-source licensing and usage can be overwhelming, especially for start-ups and SMEs, who do not have enough resources to hire an expert/consultant for IP issues. Licencing strategies are a challenge to both types of companies that we interviewed – the 3Os user companies and maker/contributor companies. This challenge seems to be more manageable in large companies where they have enough resources to approach this issue professionally. All the interviewed large companies have adopted specific strategies to address intellectual property (IP) issues related to their products or services. These strategies are designed to ensure legal compliance, manage risks, and maintain a balance between using open solutions and protecting their proprietary assets. All the interviewed large companies have an in-house legal expert, responsible for IP management issues, or an external legal consultant. All large companies work a lot on licensing strategies and licensing compatibility. On the other hand, start-ups and SMEs take ad hoc decisions to address IP issues, as they lack knowledge and resources to develop specific IP strategies.
The ad hoc process can either be internal or external. One of the benefits of the ad hoc processes is flexibility. Some companies considered IP or license management being quite straightforward, whereas others acquired external legal consultancy.
Some companies identified a more standardized way of handling the IP and license management issues, such as internal checks, screening, and processes. These internal mechanisms included, e.g.:
- using try-outs before decision-making,
- assessment of the benefits and limitations of using a specific open-source component,
- having allowed and non-allowed categories of licenses (such as no copyleft, no GPL, or no MIT),
- using predetermined development tools,
- using license compatibility checks or tools,
- avoiding unusual licenses,
- IP and licensing strategies with continuous
It is clear from the answers of some companies that their approach to intellectual property management issues has changed/developed over time. At the beginning, the companies generally didn’t have any IP management strategy, their approach was aimed only at legal compliance. Over time, as they grow from start-ups to SMEs (or large companies), they develop specific IP strategies. Not all of them rely on open innovation – some companies take a proprietary approach; others rely on a business secret approach. Their IP strategy differs also on the basis whether they are 3Os users or contributors. As 3Os users, they usually follow the IP management requirements set up by the open tools they use. As 3Os makers/contributors, they offer their product under different licenses, from strictly proprietary to fully open (or even without a license).
Evolution of businesses based on 3Os
Companies have varying approaches to 3Os based businesses, and the approaches may change in time. They mainly start with the use of open licenses to simplify their own work. The approach can then change subsequent to different business models. Dual licensing, where companies offer their software under both open-source and proprietary licenses is one possibility. Another way is the “freemium” approach, where you differentiate between a limited version and a premium version with more features. A tendency to a more open minded ecosystem approach can be seen.
A typical way of evolution of a company’s 3Os based business could be described as follows:
The interviews indicated that developers start to use OSS from the beginning of their career. Especially for repetitive tasks they use OSS and inform themselves about the proper use of licenses. Apart from OSS the companies’ business dictates whether they deal with open data or open hardware. After a while most of the companies start to provide information for the 3O-ecosystems, give feedback or contribute with open elements.
One of the first steps in the evolution of the companies mentioned in the interviews was a check of the desired license. This check can be done for instance through questions like:
- What is allowed in the use and what is forbidden?
- Is the license well maintained?
- Is a big crowd using this license?
With this experience, the use of OSS is getting more confident and expands.
First contributions are mostly feedback on used licenses or to report bugs in a license. Later some components are issued to the community. Some companies contribute to OSS as they are developing software, for instance, in governmental funded projects.
Market position and phase of the market is also important at the phase a company decides to proceed from a closed business towards a more open one. In an early market a lot of piloting and pivoting is needed. The evolution from a user to a contributor needs time and strategic decision making, as a lot of companies are dependent on selling their products or want to keep their software-as-a-service product as secret as possible.
For those companies, starting to initiate a community, there’s a need for several partners and contributors of different clusters within the ecosystem. The contributions need to be accumulated on a developed platform. After those first steps the next big issue is the standardization.
The evolution stage of operating a OSS community requires additional capabilities. Healthy ecosystems would need several partners and contributors. Partners need to agree on a standardization of the community. Quite often there is also the need for a keystone company that leads the community.
The role of ecosystems
The interviewed companies are mainly aware of being part of ecosystems involving economic and non-economic players, cooperating and competing through both value creation and capture processes. All companies recognised the advantages of being embedded in one or more ecosystems where the creation of new knowledge is facilitated by joint research work, collaboration, expertise sharing, or the development of a common knowledge base to which communities of developers, too, contribute. Ecosystems growing around the 3Os can be recognised as knowledge ecosystems, where knowledge sharing and knowledge creation are central activities. As suggested by Koening (2012), open-source communities are a well-known example of knowledge ecosystems.
Each company identifies itself into specific roles depending on the strategy, the main business, and the network structures of the company. This table summarises the main ecosystem roles in which the interviewed companies identified themselves:
Roles | Instances |
System Integrators, Platform Developers, Enablers | 7 |
Focal Firms | 2 |
Innovators | 2 |
Other Types of Networks | 2 |
Distinctive Community Roles | 9 |
Recommendations from the case studies
- Assess if doing business in your area is feasible at all without using open assets.
- Consider the non-immediate value-generation mechanisms that your contribution will potentially have.
- Take into account the quality standards required and fostered by open source.
- Reflect on the social and ethical reasons to engage in the 3Os and contribute to open assets.
- Do not forget the central role of the key developers.
- Assess how to effectively communicate the benefits of open-source solutions for your customers (e.g., security, compatibility, flexibility, avoiding vendor lock-in).
- Be clear as regards the target audience of your product(s) and which communities you will be interacting with.
- Devise risk-mitigation strategies for IP management and investments.
- Consider easy, standardized ways of managing your licenses, for instance labeling the types of licenses that fit your business model into green (can be used), yellow (subject to consideration) and red (not allowed) categories.
- Examine win-win open-source strategies for your customers.
- Understand the dynamic and evolving nature of participation in 3Os projects.
- Assess the possibilities of modularity in your business.
- Identify the open and the closed components and align them to the chosen business model.
- Unravel your technology into layers.
- Acknowledge the complementing role OD and OH take in relation to OSS.
- Understand different dimensions of the value creation in 3Os.
- Communities are key to value creation from open assets projects.