Source Data for the Focus Area Maturity Model for Software Ecosystem Governance

We define a software ecosystem as a set of organizations collaboratively serving a market for software and services. Typically these ecosystems are underpinned by a common technology, such as an extendable software platform. This data set supports the article that describes the Software Ecosystem Governance Maturity Model (SEG−M2) [50]. The model has the goal to support software ecosystem orchestrators in the management and governance of the actors in their ecosystems in a structured way. Through a critical structured literature review, 168 practices have been collected. These practices have been evaluated through six case studies at software ecosystem orchestrators. The practices are described with a practice code, a practice name, a practice description, required success conditions, the person responsible for the practice, and the associated literature where the practice was identified.


Specifications
Management of Technology and Innovation Specific subject area A focus area maturity model for software ecosystem governance Type of data Text, literature references, tables How data were acquired Systematic literature survey and evaluation in case studies Data format Raw and Analyzed Parameters for data collection The collected practices had to fit a narrow definition of that the practice had to be executable, implementable, and understandable by a member of the platform management team. Description of data collection The data was collected through a literature survey that started with an SLR [46] as its source. The data was grouped according to topical similarity. Practices were subsequently evaluated by practitioners, i.e., employees at the platform orchestrators who were responsible for the success of the platform and its orchestration. If more than 2 practitioners found the practice relevant and useful, they became part of the collection. For information on selection of the practitioners, we refer to the related research article [50] . Data source location The articles are cited in this brief. Furthermore, we report on the companies in the associated research article [50] . Data

Value of the Data
• The data can be used by software ecosystem researchers for evaluation, validation, and extension of the model • The data can be used by focus area maturity researchers to establish the vocabulary used in the field • The data can be used by software ecosystem researchers as a basis for future research work in the domains of platform management and data ecosystem management • The data are reusable by consultants in providing platform providers with knowledge about how to govern their ecosystem • The data are reusable by consultants and practitioners to assess whether they have implemented a practice fully

Data
The data are a set of practices that can be used by keystone organizations to evaluate the management and governance of their ecosystems and together make up a focus area maturity model for software ecosystem governance evaluation. The practices are deeply rooted in both empirical experience, the desk studies, and literature. The practices have been described using the following elements: • Practice code -The practice code is made up of three numbers. The first number concerns the focus area, the second number the capability, and the third number the maturity level.
As there are empty elements in the matrix, the numbers are not consecutive. • Practice -The name of the practice, as it is mentioned in the SEG-M 2 .
• Focus area -The focus area is mentioned to indicate the domain in which this practice is relevant.
• Description -A paragraph of text is provided to describe the practice in detail. The main reason for providing a lengthy description is internal validity: in future evaluations by third parties, they should be able to perform the evaluations independently. • When implemented -Provides a series of necessary conditions before this practice can be marked as implemented. Again, to strengthen internal validity of the SEG-M 2 . • Role responsible -One of the main findings during the case studies was that managers wanted to know who should be responsible for implementing a particular practice. This is now part of the SEG-M 2 as well. The roles are indicators, as the naming in companies can be different and domain specific. • Literature -Several references are given to articles that mention the practice. The literature is mainly found in the mentioned SLRs. Please note that these bibliographic entries can also be found in the data file ecosystems.bib. The citation codes used in the JSON file are referred to with their bibtex identifier.
Recently, we have created an online version of the focus area maturity model on the web site https://maturitymodels.org .

Experimental Design, Materials, and Methods
The full description of how this data was acquired is provided in the accompanying article [50] . The practices were found by taking the literature studies of Manikas [51] and Alves et al. [52] as a starting point. We analyzed the papers mentioned in these studies and identified the practices in them, by collaboratively searching through these articles and confirming the practices with both researchers. After this, we snowballed one level deeper into the existing articles and found some newer works that also contained usable practices for the maturity model.
We defined a practice as any practice that has the express goal to change the position of the platform in the software ecosystem , for instance by standardizing partnering capabilities. A second criterion is that the practice has to be executable by an employee of the platform orchestrator and has to have one role assigned to it as a responsible.
The SEG-M 2 went through two evaluation cycles. First, the cases were evaluated against sixdesk studies, which looked at existing materials of existing companies, mostly by literature study, old case materials, and online platform descriptions. In the second cycle, the SEG-M 2 was evaluated and complemented with empirical case studies, each comprising 5 days or more on site, through six software ecosystem governance maturity evaluations at four orchestrator organizations. The model was not significantly changed after the first cycle. Saturation was not purposefully reached, but the case participants indicated that the model provided an effective mechanism for the improvement of their software ecosystem management practices. Three of the case companies are still using the models to evaluate their software ecosystem management practices.

Associate Models
Partner Promotion and Grooming Practice Name :Create a professional training organization Description: The organization must value highly of employee training and create a professional training organizations, such as company academy. Also, the organization must set requirement for employees to get training for promotion. In addition, the organization must train specific types of staff, including domain specialists, technical or business consultants and sales partners. Implemented when: • The organization values talents and intents to cultivate talents within the organization for the purpose of loyalty. • The organization starts establishing company academy and certifying developers and consultants.
• The organization also certifies organizations based on the amount of training their employees have had Literature: [3,5] Responsible:Partner Manager Practice Code :1.6.4 Practice Name :Certification based on training Description: The organization must approve the outcome of professional employee training program. And therefore, the organization must provide either internal or external certification based on training. Implemented when: • The organization improves the training program by adding certified approval. • The organization values talents and thinks of employees' future career path Literature: [10] Responsible:Partner Manager Practice Code :1.6.6 Practice Name :Partner employee management Description: The organization maintains a record of all certified professionals working at partners in the ecosystem. Their data is kept up to date, so that when particular knowledge is needed in a region, the platform provider can supply potential candidates. Implemented when: • A record is kept of all certified professionals, including their employers Literature: [3,5] Responsible:Partner Manager Associate Models

Partner Promotion and Grooming
Practice Code :2.2.1 Practice Name :Support partners with quality Description: The organization must help partners to guarantee the application quality and support partners to avoid or solve potential quality issues. Moreover, the organization must form special groups or support teams. Implemented when: • The organization provides quality guidelines to partners Literature: [3,5] Responsible:Quality manager Practice Code :2.2.3 Practice Name :Platform sandbox Description: The organization must establish an environmental platform sandbox that developers can use to simulate the features and characteristics of the production environment. Moreover, the organization must create simulated responses from the applications relying on the platform and test the applications' reaction. Implemented when: • The organization relies on the platform as the core in a way as a database or user interface are considered core components to the architecture. • The organization wants to fully test the performance of the platform Literature: [20,21] Responsible:CTO & Product Manager Practice Code :2.2.4 Practice Name :Detect quality issues Description: The organization must identify quality issues in extensions and the platform and report these back to the extension developers. Implemented when: • The organization test drives extensions and reports quality issues back to the developers. Literature: [19][20][21] Responsible:Quality & Community Managers Practice Code :2.2.5 Practice Name :Share issues with partners Description: The organization must share issues detected in the platform. In addition, the organization must give partners visibility into the work stream and restrict visibility of issues within a project. Implemented when: • The organization targets to fully engage partners in the development process. • The organization collaborates with partners closely and aims to form a healthy and trustworthy relationship Literature: [3,5] Responsible:Quality & Community Managers Practice Code :2.2.7 Practice Name :Create operation knowledge portals Description: The organization provides extension developers with knowledge of how the extension performs in the field. Implemented when: • The organization provides partners with dashboards and reports about how the extension performs in the field. • Error and crash reports are sent to the extension developer Literature: [22] Responsible:Quality Manager Practice Name :Partners help partners Description: The organization must establish a mechanism for partners to seek help from other partners. In other words, the organization must form a community or channel a method for partners to exchange knowledge and to offer help freely. Implemented when: • The organization has long-term cooperation and collaboration with partners. • The organization provides a channel, such as an on-line forum, for partners to support each other Literature: [3,5,25,26] Responsible Practice Name :Automated testing Description: The organization must automate repetitive but necessary tasks in a formalized testing process, or perform additional testing that would be difficult to do manually. Test automation is critical for continuous delivery and continuous testing. Implemented when: • The organization uses separate software to control the execution of platform tests Literature: [18,27,28] Responsible:Test & Release Managers Practice Code :2.4.5 Practice Name :IDE extensions Description: The organization delivers IDE extensions to make development easier. These extensions can range from simple SDKs, tool tips, and even complete new IDEs to integrate all the features from a particular platform. Implemented when: • The organization delivers support tools for the IDE that partners use Literature: [9,18,22,28] Responsible:Release Managers Practice Code :2.4.6 Practice Name :Automated releasing Description: The organization must combine the capabilities of deployment automation, environment management and modeling, and release coordination. Moreover, the organization must package, deploy, and update an application from development, across various environment, and to production. Implemented when: • The organization helps to provide a combination of automation, environment modeling and work-flow management capabilities. • The organization helps to deliver software rapidly, reliably and responsibly Literature: [18,22,28] Responsible Practice Name :List of extensions Description: The organization maintains a list of extensions in the run up to an app store or app delivery platform and publishes the list to outsiders. In the mean time, the organization must consider quality rating from customers and develop mechanism for approving extensions into the list. Implemented when: • The organization creates a list of extension with links to partners and uses it for demo purposes to win over extenders Literature: [18,27,28] Responsible:Community & Partner Manager Practice Code :3.1.5 Practice Name :App Store Description: The organization creates marketplaces for applications that are available for download and purchase. These are presented through a market mechanism, such as an app store. Implemented when: • The organization allows developers to sell and distribute their products to actors within one or more multi-sided software platform ecosystems Literature: [17] Responsible:Release & Product Managers & CTO Practice Code :3.1.6 Practice Name :Microservice architecture Description: The organization designs software applications as suites of small independently deployable services, each running in its own process and communicating with lightweight mechanisms, to enable scalable architectures. Also, the organization must build these services around business capabilities. Implemented when: • The organization builds applications as suites of services.
• Third party services are adopted in the ecosystem through an orchestration framework Literature: [34] Responsible:Chief Architect Practice Code :3.1.7 Practice Name :Dynamic app composition Description: The organization must define an application as being dependent on another application, such as middleware or a plug-in. Also, the organization includes mechanisms to orchestrate the interaction among applications and therefore provides functionality to program the behavior of the active space. When all mechanisms are in place, apps can self-select dependent extensions, to dynamically create new solutions Implemented when: • The organization provides an architecture with pre-defined interfaces that enables automated app composition. • Based on customer problems, new compositions are created by an intelligent extension or automated service composer Literature: [28,35] Responsible Practice Name :One-click install of integration Description: Extensions can be installed without complicated installation procedures. Extensions are typically made available through an app store or App Index. The delivery mechanism has been perfected to manage the extension as a separately managed component to the platform. Implemented when: • Extensions can be installed with one click, similar to apps Literature: [18,28] Responsible: Practice Name :On-demand applications Description: Software extensions can be installed without interference of a partner or the platform owner. Customers install the applications when they need them and can delete them independently. Implemented when: • Applications can be installed automatically, for instance using a dependency mechanism Literature: [3,17,18,18,28] Responsible Practice Name :Sharing licenses with partners Description: The organization provides partners with access to licenses for the product manufacturing and publishing. Also, the organization must share the intellectual property of some products. Implemented when: • The organization agrees with partners for higher transparency over intellectual property and collaboration Literature: [5,36,37] Responsible:Product & Partner Managers Practice Code :4.1.7 Practice Name :Automated checking of license violations Description: The organization checks license violations. In addition, the organization must prioritize the intellectual property share and violation in order to avoid legal problems. Implemented when: • The organization owns several license and needs automated checking to keep license valid. • All submitted extensions are checked for license violations, based on the extensions currently available in the organization's market Literature: [25,36] Responsible Practice Name :Patents created for the platform Description: The organization must support patent related processes and creates new intellectual property for the platform. The patents are used to protect the platform and as an indication to outsiders that the platform is continuously innovated on. Implemented when: • Patents are created for technologies within the platform Literature: [15,16] Responsible:CTO Practice Code :4.3.6 Practice Name :IP sharing with partners Description: Partners get access to source code, patents, etc. These are provided to partners to enable them to innovate beyond the scope of the platform. Implemented when: • The organization shares intellectual property with partners. • The organization distributes innovations that it does not use to its partners Literature: [5] Responsible:CTO Practice Code :4.3.7 Practice Name :Patent violations identified Description: The organization must prohibit the act of patent infringement with respect to a patented invention or product. Therefore, the organization must be able to identify possible violations for patent use according to local jurisdiction. Implemented when: • The organization identifies patent infringement and coordinates violations when they occur Literature: [27,36] Responsible Practice Name :Promotion of partner solutions to other developers Description: The organization promotes extensions and tools to other extenders, for instance to show the success of other partners. Moreover, the organization provides customer case examples to partners and extenders. In particular tools that speed up development are shared often and early. Implemented when: • The organization actively looks for the best developer stories and the most innovative solutions. •The organization actively promotes solutions and encourages partners to sell software to partners Literature: [5,9] Responsible:Community & Partner Managers Practice Code :7.3.4 Practice Name :Show partner innovations to partners Description: The organization must foster a culture of innovation. Therefore, the organization must show cutting-edge or valuable innovations of partners as examples to partners and cultivate the atmosphere of coming up with new ideas and worthwhile breakthroughs. Implemented when: • The organization sets innovation display cases for partners to lure and attract more innovations from and for the ecosystem. Literature: [5,49] Responsible:Community & Partner Managers Practice Code :7.3.6 Practice Name :Reward new innovations Description: The organization stimulates new innovations within the ecosystem and rewards new ideas and thoughts to bring about a positive loop of innovation and development. Moreover, the organization evaluates innovations carefully. The innovation reward compensates part of the risk of failure. Implemented when: • The organization values innovations and formalizes a mechanism to reward innovation. Literature: [49] Responsible Practice Name :Formal road map presentation Description: The organization organizes conferences or meetings to present the road map. Also the organization discusses ideas and road maps with partners and participants in the ecosystem. Moreover, the organization is open to all valuable innovations and improvement suggestions from others. Finally, the organization makes sure the road map items are published when they need to be published and avoids information leaks. Implemented when: • The organization organizes and presents road maps in a formal way. • The organization has a communication policy regarding the road map. Literature: [32] Responsible:Product & Release Managers Practice Code :7.4.7 Practice Name :Collaborative road maps Description: The organization shares road maps with partners and makes their tools and solutions part of the road map. In this way, customers are aware of the partner solution co-evolution. Implemented when: • The organization creates road maps in collaboration with strategic partners. • Partner road maps are taken into account and collaboratively coordinated. Literature: [5,9,32] Responsible:Product & Release Managers

Declaration of Competing Interest
None.