The Open Source Officer Role – Experiences
- First Online:
- Cite this paper as:
- Mols CE., Wnuk K., Linåker J. (2017) The Open Source Officer Role – Experiences. In: Balaguer F., Di Cosmo R., Garrido A., Kon F., Robles G., Zacchiroli S. (eds) Open Source Systems: Towards Robust Practices. OSS 2017. IFIP Advances in Information and Communication Technology, vol 496. Springer, Cham
This papers describe the Open Source Officer role and the experiences from introducing this role in several companies. We outline the role description, main responsibilities, and interfaces to other roles and organizations. We investigated the role in several organization and bring interesting discrepancies and overlaps of how companies operate with OSS.
KeywordsOpen source governance Inner-source Maturity models
Several companies have discovered and utilized the extensive benefits that Open Source Software (OSS) brings to their product development activities and processes. As any OSS adoption is an organizational change and often a cultural shift, there is a need for supporting role that ensures these transformations are smooth and directed towards achieving higher maturity models in operating with OSS .
In this paper, we present the Open Source Officer Role and discuss the experiences from establishing this role in three organizations. We outline the most important challenges that the role installation brings and outline the research agenda for further research activities.
2 The Open Source Officer Role Description
The sourcing organization plays an important role here as it is responsible for negotiating contracts with component suppliers for the non-OSS components and for hardware components that come with software that can be proprietary and/or OSS. The sourcing organization has the task to secure that suppliers are fulfilling the obligation of the OSS licenses (are OSS compliant) in the delivered software. It also can support the search and selection of the best sourcing strategy (with the OSS as the priority) given the set of functional and quality requirements that a given component should deliver.
Governance and support systems - The Open Source Officer is a part of Open Source Operations and in charge for governance and support, including processes etc.
Education - the officer identifies the education needs in an organization as well as ensures that needed education is provided to the organization.
Developer Engagement - The OSO leads and mentors the software organizations in the engagement in OSS projects (maturing and taking on their responsibilities). The organizations take the formal responsibility for the OSS engagement activities.
Business Models - although having no direct responsibility, the OSO should engage in business strategy development discussions to influence, support, and advice business entities to enable a full advantage of using OSS in generating and sustain business.
Leadership and Culture - The OSO can support and advice in the creation of organization and leadership culture that is suitable for ensuring extensive benefits from OSS. The actual task of creating an organization is the top management responsibility.
Strong leadership skills are required as a central part of the role is to develop and manage governance and support systems as well as the education program required to advance in the open source maturity.
Communication skills - strong written and verbal English skills are required as the role involves communication with local and global organizations – including company external organizations, e.g. purchasing a training course from an external company.
Functional and technical skills - good change management skills are required as the role supports the changes in the mindset of individuals, support required transformation of organizational structures as well as influence the culture of the organization. Good understanding of OSO that is reaching beyond the basic copyright issues or OSS compliance, business and market logic implications as well. Good understanding on the fundamentals of software engineering.
Technology knowledge - the OSO need to be a very good generalist and understand the technological aspects of software as well as other aspects. This is particularly important for OSOs not originating from software organizations.
Engage actively in the Open Source Board operations - the Open Source Board is the governing function for Open Source within the company or a business unit. The two main tasks for the board involve: (1) Maintaining the corporate policies set by the executive management regarding OSS operations and ensuring that the documentation is up to date, and (2) Vetting and approving contribution proposals and ensuring that both business needs and IPR are taken into consideration.
Ensure that Open Source related processes and trainings are provided - that includes ensuring that the processes are defined, documented and implemented in relevant organizations and that the training is provided.
Act as an interpreter between engineers and lawyers - ensure that OSS related questions gets timely answered and that engineers and developers are proactive and positive about using OSS components without unnecessary license related fears.
Act as the company’s external interface in Open Source related questions - especially for the questions related acquisitions and compliance of the released products.
Act as an internal management consultant - that reacts to any request for help or support about the OSS operations or knowledge.
Authorities - the OSO has a deciding voice as one of the members of the Open Source Board and can propose changes to OSS related directives and processes.
3 Experiences from Three Software-Intensive Organizations
Company A is the develops software-intensive products for global market in a matured market where several strong vendors established their position. The company joined the OSS ecosystem in 2007 and within three years dropped all other platforms and based all the product on this OSS platform. The company is currently on level 4 in of OSS maturity . The scope and responsibility of the OSO role is described in Fig. 1 and in Sect. 2. One important remark is that the OSO in this case does not take the responsibility for compliance or running OSS-related software projects.
Company B is a direct competitor to company A and apart from software-intensive embedded systems the company is also active in several other business units that produce home electronics, automotive, chemical and heavy industry. Our analysis is based on an interview with the OSO from the same business unit as company A. The main difference at company B is that OSO is also responsible for a group of about 80 developers that maintain the critical components based on OSS code that are reused in several business units. The OSO is a project manager for these activities. Another difference is that the OSO acts as an authority regarding legal and IPR questions and have no dedicated OSS-knowledgeable lawyer to closely collaborate with.
Company C manufactures trucks, buses and engines for heavy transport applications for a global market and experienced an increased dependence on software and is currently transforming into a software-intensive product development organization. The OSO role differs in two aspects: (1) the OSO is also a project manager that is responsible for running OSS-based software projects (not the core part like at company B) and (2) the OSO needs to have the required technical knowledge about software and its architecture to support the transformation to a software-intensive company.
Kemp  suggests the introduction of an OSS Compliance Officer (OSSCO) with the responsibility of developing and implementing the OSS governance mechanisms, agree on an internal OSS strategy (e.g., expressing where and why to use OSS) and oversee that it is followed, mainly from the possible IP leakage and compliance issues. Much of the responsibilities of an inner-source champion  align with the role of an OSSCO as proposed by Kemp  and with the OSO role.
4 Conclusion and Future Work
In this experience report we have described the role of an Open Source Officer (OSO). The OSO role offers a central authority and champion that can help an organization to both introduce and mature in their use of OSS. The presented role description is based on knowledge and experience gained from Sony Mobile and confronted with interviews at two other large organizations that use OSS in their products. Future work will further investigate how the role description may fluctuate in organizations with differing characteristics, but also how the surrounding organizational structure of the OSO can be defined, e.g., in regards to OSS governance board.
This work was funded by the ITEA2 project 12018 SCALARE, and by the IKNOWDM project [grant number 20150033] from the Knowledge Foundation in Sweden.
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter’s Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter’s Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.