diff --git a/.github/linters/markdownlint.yml b/.github/linters/markdownlint.yml new file mode 100644 index 0000000..aae7155 --- /dev/null +++ b/.github/linters/markdownlint.yml @@ -0,0 +1,8 @@ +# Default state for all rules +default: true +# MD013 - line-length +MD013: false +# MD024 - Multiple headers with the content +MD024: false +# MD033 - Inline HTML +MD033: false diff --git a/.github/workflows/linter.yaml b/.github/workflows/linter.yaml new file mode 100644 index 0000000..d6be4ab --- /dev/null +++ b/.github/workflows/linter.yaml @@ -0,0 +1,54 @@ +--- +################################# +################################# +## Super Linter GitHub Actions ## +################################# +################################# +name: Lint Code Base + +############################# +# Start the job on all push # +############################# +on: + push: + branches: [main] + pull_request: + branches: [main] + +############### +# Set the Job # +############### +jobs: + build: + # Name the Job + name: Lint Markdown + # Set the agent to run on + runs-on: ubuntu-latest + + ################## + # Load all steps # + ################## + steps: + ########################## + # Checkout the repo # + ########################## + - name: Checkout Code + uses: actions/checkout@v3 + with: + # Full git history is needed to get a proper + # list of changed files within `super-linter` + fetch-depth: 0 + + #################################### + # Run Linter against documentation # + #################################### + - name: Lint markdown + uses: github/super-linter@v5 + env: + VALIDATE_ALL_CODEBASE: true + DEFAULT_BRANCH: main + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + VALIDATE_MARKDOWN: true + MARKDOWN_CONFIG_FILE: markdownlint.yml + FILTER_REGEX_INCLUDE: .*Contribution-.*.md + diff --git a/Contribution-1-Ind.md b/Contribution-1-Ind.md index 5b89eac..e2ec683 100644 --- a/Contribution-1-Ind.md +++ b/Contribution-1-Ind.md @@ -6,72 +6,75 @@ has_children: true permalink: /Contributions-1-Ind --- - ## Open Source Contributions + Contributions to open source projects can be of widely varying content, complexity and motivation. Therefore, contributions can be categorized into different classes and types to allow for providing concrete guidance for each. In general, there are two separate classes of contributions: -1. contributions to existing open source projects, and -2. the creation of new projects, including open sourcing entire proprietary code bases. +1. contributions to existing open source projects, and +1. the creation of new projects, including open sourcing entire proprietary code bases. These two classes differ significantly in terms of motivations, (business) reasons as well as legal considerations and practical execution. Therefore, Section 3 will cover each class separately. Within the class of contributions to existing projects, contributions can be of very different nature, both in terms of technical complexity as well as in terms of what is being contributed. Regarding technical complexity, contributions can range from simple bug fixes (e.g., typos) to the addition of complex new features. Moreover, contributions are not limited to source code, but generally include any form of content (e.g., documentation), information (e.g., bug reports and feature requests) or support (e.g., infrastructure, marketing, release management). Each type of contribution may require a different approach, both regarding engaging with an open source project as well as company-internal processes. Therefore, this material differentiates five types of contributions to existing open source projects: -1. Bug reports and feature requests, -2. Bugfixes and corrections, -3. Supporting contributions, -4. Individual features, and -5. Strategic industry leading engagements. +1. Bug reports and feature requests, +1. Bugfixes and corrections, +1. Supporting contributions, +1. Individual features, and +1. Strategic industry leading engagements. **Bug reports and feature requests:** This type of contribution typically does not comprise source code, but instead is feedback to the project regarding incorrect behavior of the software, e.g., a bug report, or a request and value argumentation for a new feature. As those reports or requests typically do not comprise code (apart from potentially fractions of pseudocode), contributors fully rely on members of the development community to pick up these requests for implementation. **Bugfixes and corrections:** Bugfixes are corrections of unintended and/or incorrect behavior of a software, in particular including vulnerabilities, often in response to bug reports. Bugfixes implement changes and/or additions to a code base within the scope of existing functionality. Therefore, bugfixes modify existing code, but can also add new code for handling previously unhandled scenarios or corner cases in the existing logic. Outside of such additions, bugfixes do not add new functionality to a codebase. Bugfixes are typically small in terms of the number of changed lines of code. **Supporting contributions:** Supporting contributions are improvements of an open source project outside of the core functional scope of a project, but instead they are supportive in nature, aiming to improve a project’s maturity and adoption. Such contributions comprise for example: -- improvements of a project’s documentation, -- its build system, -- test cases and frameworks, -- release management, -- code reviews, and -- presentations + +* improvements of a project’s documentation, +* its build system, +* test cases and frameworks, +* release management, +* code reviews, and +* presentations **Individual features:** Individual contributions address gaps in the functionality of an open source software component used in a product. This may comprise functionality for supporting industry-specific use cases, or improvements of the software to meet specific robustness and performance requirements. Therefore, the key value of closing a functional gap in an open source component is the enablement of higher-level value in the form of a better functioning product. **Strategic industry leading engagements:** Strategic engagements aim to drive the evolution of open source technology of strategic relevance to a company and to establish an organization in an industry leading position in key open source projects. Strategic engagements often comprise appointing a development team to continuously make the above-mentioned types of contributions (from bugfixes to individual features) with the intention that team members take on Owner/Maintainer/Committer roles (see Section 1.3.3) in the project over time. Strategic engagements comprise both, i) projects which are hosted by open source foundations (e.g., Linux Foundation), and ii) projects created, hosted and governed by a company. ### Open Source Projects, Culture and Roles + It is important for everybody who engages in the open source ecosystem to understand its structure, culture, and social norms. This section provides a brief overview of the governance of open source projects, the purpose of open source foundations and the various roles developers within an open source project can play. ![image](https://github.com/ExpertLearningLab/foss-learning/assets/126161450/18a93818-b7a2-49b1-a219-dfe38d0d3697) - ### Project Structure and Governance + The open source ecosystem is extremely heterogenous, i.e., open source projects differ greatly in terms of size of the development community, industry adoption, and governance models. In terms of size, projects range from single-developer hobbyist activities to large scale industry driven projects such as the Linux kernel, OpenStack, or Kubernetes. ![image](https://github.com/ExpertLearningLab/foss-learning/assets/126161450/bf69b10c-07bd-47dd-a770-b325c920e5eb) - Similarly diverse is the governance structure of projects, ranging from a single developer-lead model, sometimes also referred to as “Benevolent Dictator for Life” (e.g., the Linux kernel), via company-controlled projects (e.g., Android), to fully meritocracy-based governance models (e.g., OpenStack, Kubernetes). Meritocracy refers to a governance model in which the most valued contributors to a project obtain leadership positions in the project, often based on project-wide elections. Projects controlled by a single company typically lack community-based governance fora such as Technical Steering Committees, and more prominently, all Committers (see description of developer roles in Section 1.3.3) among the developers are employed by the controlling company, thereby gatekeeping all code going into the codebase. -Additionally, the size of the development community is an indicator of the adoption of a project, but not at all a clear cut criterion. Some widely used open source projects are maintained by just a small group of developers, despite being leveraged across countless commercial and non-commercial software. Famous examples are log4j or openssl. +Additionally, the size of the development community is an indicator of the adoption of a project, but not at all a clear cut criterion. Some widely used open source projects are maintained by just a small group of developers, despite being leveraged across countless commercial and non-commercial software. Famous examples are log4j or openssl. Given all this diversity, organizations and developers who intend to i) utilize and consequently ii) engage in open source must be aware of the nature of the development community and take their respective ways-of-working into account. -### Open Source Foundations +### Open Source Foundation + Open Source Foundations are non-profit organizations which facilitate the development of open source software projects. Their goal is to establish a neutral space within which organizations – commercial or non-commercial, competing or non-competing – can jointly participate in the development of open source projects. To this end, foundations provide, among others, services such as a -1. A vendor-neutral and meritocracy-based governance structure to ensure that no single organization steers the technical roadmap of a project and that instead project leadership positions are held by the most active and valued technical contributors, -2. marketing and event organization to support industry adoption of a project, -3. development infrastructure such as cloud hosting resources and CI/CD infrastructure, and -4. dedicated staff for handling project and release management. +1. A vendor-neutral and meritocracy-based governance structure to ensure that no single organization steers the technical roadmap of a project and that instead project leadership positions are held by the most active and valued technical contributors, +1. marketing and event organization to support industry adoption of a project, +1. development infrastructure such as cloud hosting resources and CI/CD infrastructure, and +1. dedicated staff for handling project and release management. Commercial and non-commercial organizations can moreover join a foundation and/or a respective project hosted by a foundation as a member. Membership typically involves a membership fee and depending on the membership level, the member organization receives different benefits, such as a seat on the governing board which oversees how the membership budget is spent. Examples of open source foundations include the Linux Foundation, the Eclipse Foundation, the Apache Foundation, the Mozilla Foundation, and various smaller ones. ### Developer Roles + Despite the aforementioned diversity among open source projects, developers within a project typically hold one or more specific roles. ![image](https://github.com/ExpertLearningLab/foss-learning/assets/126161450/48f6b5b9-3713-4549-b087-bf87dc74f13d) @@ -80,12 +83,12 @@ _Hierarchy of roles in an open source project._ These roles in fact exhibit a hierarchical structure as shown in Figure 1 and can be categorized as follows from bottom to top: -• **Consumers** – These members of the community comprise the userbase which utilize a project in another commercial or non-commercial software. Consumers can provide valuable feedback regarding features, bug reports, and more. However, as they are not involved in the development process itself, they have little influence on how their feedback is being considered and addressed by developers. +* **Consumers** – These members of the community comprise the userbase which utilize a project in another commercial or non-commercial software. Consumers can provide valuable feedback regarding features, bug reports, and more. However, as they are not involved in the development process itself, they have little influence on how their feedback is being considered and addressed by developers. -• **Contributors** – Even though everybody who provides feedback or input to an open source project effectively contributes to its development (see Consumers), the term Contributor, as used in the open source community at large, specifically refers to developers who make contributions to the content of a project, be it code or documentation. Moreover, they participate in reviewing contributions by other developers. Contributors are therefore familiar with the technical details of a project, but they are not able to submit/merge proposed code changes to the code base. +* **Contributors** – Even though everybody who provides feedback or input to an open source project effectively contributes to its development (see Consumers), the term Contributor, as used in the open source community at large, specifically refers to developers who make contributions to the content of a project, be it code or documentation. Moreover, they participate in reviewing contributions by other developers. Contributors are therefore familiar with the technical details of a project, but they are not able to submit/merge proposed code changes to the code base. -• **Committers** – Developers with ability to merge new code into the repository. Therefore, they act as gate keepers. In addition, they are actively participating themselves in code development and review the contribution proposals. +* **Committers** – Developers with ability to merge new code into the repository. Therefore, they act as gate keepers. In addition, they are actively participating themselves in code development and review the contribution proposals. -• **Maintainer / Owner** – Maintainers drive the vision, goals and technical architecture of the project. Depending on the size of the project, there may only be a single maintainer, for instance the original author/owner of a project, or a group of maintainers, each responsible for a specific subsystem of the code. An example for this is the Linux kernel and the maintainers of the respective subsystems. Maintainers are most deeply familiar with the code base and actively take part in code development and review. +* **Maintainer / Owner** – Maintainers drive the vision, goals and technical architecture of the project. Depending on the size of the project, there may only be a single maintainer, for instance the original author/owner of a project, or a group of maintainers, each responsible for a specific subsystem of the code. An example for this is the Linux kernel and the maintainers of the respective subsystems. Maintainers are most deeply familiar with the code base and actively take part in code development and review. Developers generally rise in the hierarchy of a project based on the quality of their technical contributions. Additionally, rising through the ranks requires a steady involvement in the project over an extended period of time. Moreover, even the highest level of project leadership, maintainers and owners, actively participate in code development. There is usually no such role as a non-coding architect. diff --git a/Contribution-2-Ind.md b/Contribution-2-Ind.md index c939059..f205ba7 100644 --- a/Contribution-2-Ind.md +++ b/Contribution-2-Ind.md @@ -7,53 +7,56 @@ permalink: /Contributions-2-Ind --- ## Business reasons for engaging in open source software development + When a company actively participates in open source software development by contributing code, resources, or expertise to open source software projects, it can derive several strategic advantages. Contribution is not just an act of goodwill but should be treated as a strategic move that aligns with the company’s broader goals and objectives. ![Business_Reasons](./Contrib_ch2_Business_reasons.jpg) ### Strategic advantages of open source software contribution + Engaging in open source software contribution can align seamlessly with strategic business objectives, if done right. By using readily available open source components, companies can avoid reinventing the wheel and allocate resources more efficiently. Moreover, participating in open source communities can position a company at the forefront of innovation, providing access to emerging technologies and methodologies that can be integrated into their offerings. The important aspect of participating is to accelerate the evolution of a new technology and make it suitable for ones use cases. Consumption alone leaves you with what’s available. This engagement also expands market reach, tapping into a global pool of users and developers. Importantly, making appreciated contributions will also enhance a company’s influence and reputation within these communities, which can be a vital enabler for its open source strategy. -Strategic engagement in open source development can be crucial for securing a reliable technology supply. This involves identifying open source software components that are critical to the company's operation and developing a strategy to ensure their continued availability. By actively contributing to these components, a company can safeguard its technology supply, retaining the ability to use and adapt these components as needed. +Strategic engagement in open source development can be crucial for securing a reliable technology supply. This involves identifying open source software components that are critical to the company's operation and developing a strategy to ensure their continued availability. By actively contributing to these components, a company can safeguard its technology supply, retaining the ability to use and adapt these components as needed. Another strategic approach involves leveraging "early adopters" within the community. Early adopters can provide valuable feedback on new ideas or technologies at an early stage. By engaging the users in the community, a company can assess how a new technology or idea will be received before committing significant investments. This approach allows for agile adaptations based on real-world feedback, ensuring that developments are in line with community needs and expectations. -In the landscape of open source software, traditional business strategies, especially those involving financial influence, often need reevaluation. While many companies may use money to exert influence, this approach is not necessarily effective in open source environments. Unlike traditional business models where financial power drives decisions, open source software projects are primarily influenced by contributions. These contributions, whether in the form of code, expertise, or community support, are the true currency of influence in the world of open source software development. +In the landscape of open source software, traditional business strategies, especially those involving financial influence, often need reevaluation. While many companies may use money to exert influence, this approach is not necessarily effective in open source environments. Unlike traditional business models where financial power drives decisions, open source software projects are primarily influenced by contributions. These contributions, whether in the form of code, expertise, or community support, are the true currency of influence in the world of open source software development. Strategic engagements are closely tied to a long-term business strategy and require substantial staffing and long-term commitment. ### Product development through open source software -The open source model offers a unique advantage in product development. By using de-facto industry standard open source software components, a company can build its product(s) leveraging those and thereby accelerate product development. However, relying on these components also involves a degree of dependency on the community for updates and support. To mitigate risks such as delayed community support, companies can develop solutions or bug fixes and then contribute this back to the community for mutual benefit. This relationship results in easier maintenance, faster feature development, and overall higher quality. Contributions should be closely aligned with the strategy and roadmap of a product to ensure business relevance. + +The open source model offers a unique advantage in product development. By using de-facto industry standard open source software components, a company can build its product(s) leveraging those and thereby accelerate product development. However, relying on these components also involves a degree of dependency on the community for updates and support. To mitigate risks such as delayed community support, companies can develop solutions or bug fixes and then contribute this back to the community for mutual benefit. This relationship results in easier maintenance, faster feature development, and overall higher quality. Contributions should be closely aligned with the strategy and roadmap of a product to ensure business relevance. Additionally, open source software contributions can be strategically used for competitive advantages. Companies can initiate or contribute to open source software projects to develop new products or frameworks that are aligned with and support existing product ecosystems. This strategy can establish a company's dominance in specific technical areas. Apple's development of Swift, Google's investment in Android, and Microsoft's contribution to .NET and C# are examples of how leading tech companies have used open source contributions to create platforms that serve immediate product needs and set industry standards. Such strategic contributions allow companies to shape the technical landscape in ways that favor their products and services, which can give them a significant competitive advantage. ### Standardization strategies + Active involvement in open source software projects enables companies to influence industry standards. This strategic participation ensures that the evolving standards are aligned with the company’s interest, allowing them to influence the future direction of technology and industry practices. Moreover, actively being involved can improve interoperability with the company’s software and hardware to reduce compatibility issues. Additionally, engagement in standardization can serve a tactical purpose. Companies can drive de-facto standards through their contributions. By actively shaping these standards, companies can steer development in directions that are aligned with preferred technologies to create standards that will benefit the company’s strategic position. ### Open collaboration ecosystem + Open source software projects provide a neutral, open platform for collaboration among different stakeholders. An open approach to innovation encourages healthy competition and growth, fostering an environment where ideas can be freely exchanged and improved. The collaborative nature of open source development is not merely about code development, but it is a holistic approach involving idea sharing and problem solving to develop and enhancing software. Moreover, decisions are often facilitated made through open discussions, but maintainers typically take the final decisions. ![Open Ecosystem](./Contrib_ch2_Open_ecosystem.jpg) ### Ensuring the sustainability of open source initiatives -A common misconception about open source software is that it is “free” in the sense of having no cost. While it is true that open source software typically comes without license fees, it is crucial to understand that this does not equate to being free of cost. The vitality and attractiveness of open source projects depend on continued engagement and support. These projects thrive on the contribution of their community. Therefore, businesses must recognize the implicit costs associated with consuming open source. + +A common misconception about open source software is that it is “free” in the sense of having no cost. While it is true that open source software typically comes without license fees, it is crucial to understand that this does not equate to being free of cost. The vitality and attractiveness of open source projects depend on continued engagement and support. These projects thrive on the contribution of their community. Therefore, businesses must recognize the implicit costs associated with consuming open source. Supporting the open source ecosystem is not just about contributing code – it is about taking responsibility for the sustainability of these initiatives. Companies benefit from open source software and, in turn, have a role to play in ensuring its longevity and health through contributions, it can be code, but also infrastructure, resources, or community engagement. ### Marketing, goodwill, and employer branding + A company’s contribution to open source development can significantly enhance its market image and that is more likely to happen if the project also has a good reputation and performance. This promotes goodwill among customers and partners and boosts the company’s attractiveness as an employer. In today’s competitive talent market, a strong brand associated with innovation and community contribution can be an important decision factor for potential employees. Preparing the business to handle open source software development A company considering engaging in open source software development should as part of its preparation consider these areas: -• Governance structure - -• Contribution strategy - -• Contribution process - -• Contribution team - -• Awareness and training +* Governance structure +* Contribution strategy +* Contribution process +* Contribution team +* Awareness and training **Governance structure:** A formal governance structure with a stated ownership shall specify a company strategy & policy. It shall also include a mandated process with guidelines of how contributions are to be made with documented criteria for contribution decisions. The governance shall also provide a declaration of the involved roles with responsibility including a declaration of who owns the final decision to make the contribution or not. @@ -68,4 +71,3 @@ A company considering engaging in open source software development should as par The company could provide information fulfilling the needed basic level of open source software understanding, for instance through training. The company also should provide specific training for employees getting involved in the company contribution effort. Such training should also increase the awareness internally of the decided strategy, the roles involved and the process including the decision making. A company guideline may be provided on how contribution and external engagement shall be performed by the employees as representatives of the company. Open source contribution engagement is also an opportunity of company branding which of course depends on the selected contribution stance. - diff --git a/Contribution-3-Ind.md b/Contribution-3-Ind.md index 39aaa03..5e5885a 100644 --- a/Contribution-3-Ind.md +++ b/Contribution-3-Ind.md @@ -6,31 +6,30 @@ has_children: true permalink: /Contribution-3-Ind --- - ## The business process of making an open source software contribution ### Contributions to existing open source software projects -The business process of engaging in existing open source software projects can be set up in various ways and be subject to different governance models, depending on a company’s needs and capabilities. -Regardless of if the decision is made through an ad hoc process or if it passes through a sophisticated setup (e.g. with an Open Source Program Office (OSPO)), the process should in the end lead to the following three cornerstones: -• Purpose. A defined purpose for the specific contribution activity. -• Suitability. A suitability assessment from relevant perspectives, based on the purpose. +The business process of engaging in existing open source software projects can be set up in various ways and be subject to different governance models, depending on a company’s needs and capabilities. -• Conscious decision. A conscious decision based on the above, including the allocation of adequate and suitable resources. +Regardless of if the decision is made through an ad hoc process or if it passes through a sophisticated setup (e.g. with an Open Source Program Office (OSPO)), the process should in the end lead to the following three cornerstones: -Please note: This module does not refer to spare-time contributions made by employees outside of work. In that context, it is important to note that in most cases (either by law or contract), the copyright to a developer’s code – insofar as it falls within his or her job description – will be automatically transferred to the employer. It is generally advisable for companies to have a process to get notified about and approve employee spare-time activities that may border to or affect the day-to-day work, subject to local employment legislation. Open source software contributions are not an exception in that regard. +* Purpose. A defined purpose for the specific contribution activity. +* Suitability. A suitability assessment from relevant perspectives, based on the purpose. +* Conscious decision. A conscious decision based on the above, including the allocation of adequate and suitable resources. + +*Please note*: This module does not refer to spare-time contributions made by employees outside of work. In that context, it is important to note that in most cases (either by law or contract), the copyright to a developer’s code – insofar as it falls within his or her job description – will be automatically transferred to the employer. It is generally advisable for companies to have a process to get notified about and approve employee spare-time activities that may border to or affect the day-to-day work, subject to local employment legislation. Open source software contributions are not an exception in that regard. ### Defining the purpose of the open source software contribution -As described in module 2, there are many possible reasons for a company to engage in open source software development through contributions. When considering a specific contribution case, the task is essentially to identify which of these reasons apply to the case in question. In short: why make this contribution? -If there is no obvious answer to that question, it is likely due to one out of two reasons: -1. The company is immature in the open source software business strategic dimension, lacking sufficient capabilities, structures and/or strategies to answer the question. -See Module 2. +As described in module 2, there are many possible reasons for a company to engage in open source software development through contributions. When considering a specific contribution case, the task is essentially to identify which of these reasons apply to the case in question. In short: why make this contribution? -2. The contribution does not fit with the company strategy and is thereby questionable. +If there is no obvious answer to that question, it is likely due to one out of two reasons: +1. The company is immature in the open source software business strategic dimension, lacking sufficient capabilities, structures and/or strategies to answer the question. See Module 2. +1. The contribution does not fit with the company strategy and is thereby questionable. -On the other hand, if there is an obvious business reason to engage in a particular open source software project, the question “why” will generally be relatively simple to answer and define. +On the other hand, if there is an obvious business reason to engage in a particular open source software project, the question “why” will generally be relatively simple to answer and define. For instance, the reason may be that the company is relying on a specific open source software component which has a declining community, and the company therefore wants to boost the continued engagement and redundance in the open source software project. Defining such a purpose will immediately uncover several aspects. To begin with, to truly boost engagement in the open source software project, it is unlikely that sporadic issue reports or the occasional suggestion of a bug fix will do enough to fulfil the purpose. Instead, it is likely that the company may need to engage continuously, also with more substantial types of contributions (see module 1) and even commit to assume roles higher up in the project hierarchy (see module 1). @@ -38,173 +37,165 @@ When the question “why” is answered, the possibility to assess the contribut In companies with a mature open source development management organization and where governance has been established, standardized forms for contribution requests should preferably require the internal requester to specify the open source software project in question and the reasons for engaging in it. This can be particularly helpful in larger organizations and/or in companies with a high volume of open source software contribution requests. As a suggestion, such forms could include: -• The name and scope of the open source software project - -• Relevant links (to the repository, project website and the website of any governing body such as the relevant Open Source Foundation) - -• Information about the type(s) of contribution(s) intended - o If source code will be contributed, a specification of the same -• The reason(s) why the contribution(s) would be beneficial for the company - -• Exit criteria (if it is a continuous contribution) - -### Suitability assessment -With the intended purpose established, the next step is to assess the suitability of the contribution. +* The name and scope of the open source software project +* Relevant links (to the repository, project website and the website of any governing body such as the relevant Open Source Foundation) +* Information about the type(s) of contribution(s) intended + * If source code will be contributed, a specification of the same +* The reason(s) why the contribution(s) would be beneficial for the company +* Exit criteria (if it is a continuous contribution) -• Will the potential benefits warrant the effort needed? +### Suitability assessment -• How likely is the company to achieve the purpose by making the contribution(s)? +With the intended purpose established, the next step is to assess the suitability of the contribution. -• Are there any risks connected to the activity? +* Will the potential benefits warrant the effort needed? +* How likely is the company to achieve the purpose by making the contribution(s)? +* Are there any risks connected to the activity? One part of this assessment is of a business- and technical character, as covered in this section. The next section will cover the legal and intellectual property rights aspects of the suitability assessment. Together with the purpose, these two suitability dimensions will constitute a basis for the decision to contribute or not. -**• Resource allocation.** A fundamental question is resource allocation, which is in turn closely connected to the type of contribution. In cases of one-time bugfixes and corrections, the contribution may not demand much more than the push of a button (if the fix has already been developed internally). Such momentary cases will of course not require any significant additional resources. On the other hand, if the intention is to strategically engage in the open source software project over time, the company will need to allocate internal resources to the project, such as developers, project managers, or other necessary personnel. Consequently, for larger contribution activities, the company needs to balance the open source software project activity against other prioritized activities. In general, it is recommended to assure that a continuous contribution activity has an internal “owner” and/or that contributions are funneled through some kind of control instance, such as an Open Source Program Office (OSPO) and/or a cross-competence team set up for governance purposes. +* **Resource allocation.** A fundamental question is resource allocation, which is in turn closely connected to the type of contribution. In cases of one-time bugfixes and corrections, the contribution may not demand much more than the push of a button (if the fix has already been developed internally). Such momentary cases will of course not require any significant additional resources. On the other hand, if the intention is to strategically engage in the open source software project over time, the company will need to allocate internal resources to the project, such as developers, project managers, or other necessary personnel. Consequently, for larger contribution activities, the company needs to balance the open source software project activity against other prioritized activities. In general, it is recommended to assure that a continuous contribution activity has an internal “owner” and/or that contributions are funneled through some kind of control instance, such as an Open Source Program Office (OSPO) and/or a cross-competence team set up for governance purposes. -**• Technical and financial boundaries.** For continuous engagement in open source software projects, it may be necessary to define certain boundaries of both technical and financial character. Heavy engagement may e.g. involve paid membership in a governing body, frequent meetings and/or substantial engagement of internal developers, which suggests keeping a budget or taking other measures for cost control purposes. Further, it may also be worth considering which technical boundaries – if any – that should be settled for the contribution. Such boundaries could apply to the general project evolution, i.e. if the open source software project pivots in an irrelevant or misaligned direction, the company may have decreased strategic interest to stay involved, or face the decision whether to fork out a subproject. A technical boundary could also be necessary in terms of the contributions as such, i.e. the company may be comfortable contributing code for a particular part of the open source software project, but unwilling – for strategic reasons – to share in other adjacent technical areas. Whether expressed as formal boundaries/mandates or not, it is recommended to consider whether any such framing is needed for any given engagement. The boundaries can also be used to define exit criteria for the engagement. - -**• Brand exposure:** Once the company starts interacting with and contributing to the open source software project, it will associate its brand with the project and any company developers will represent the company brand in the context. Generally speaking, the larger the contribution/engagement, the larger the brand exposure. As such, the company should assess if there are any bad will risks entailed with being associated with the open source software project. Bad will risks may also arise if the company provides poor quality contributions or if its employees misbehave in the open source software project, e.g. acting in breach of the project’s Code of Conduct. On the other hand, being associated with an open source software project in a positive way will of course carry a potential of goodwill, thereby strengthening the company brand. The decision to support an open source software project might be an opportunity for the marketing unit to provide a press release on the topic and thus strengthening the perception of the company as an open source software friendly company. +* **Technical and financial boundaries.** For continuous engagement in open source software projects, it may be necessary to define certain boundaries of both technical and financial character. Heavy engagement may e.g. involve paid membership in a governing body, frequent meetings and/or substantial engagement of internal developers, which suggests keeping a budget or taking other measures for cost control purposes. Further, it may also be worth considering which technical boundaries – if any – that should be settled for the contribution. Such boundaries could apply to the general project evolution, i.e. if the open source software project pivots in an irrelevant or misaligned direction, the company may have decreased strategic interest to stay involved, or face the decision whether to fork out a subproject. A technical boundary could also be necessary in terms of the contributions as such, i.e. the company may be comfortable contributing code for a particular part of the open source software project, but unwilling – for strategic reasons – to share in other adjacent technical areas. Whether expressed as formal boundaries/mandates or not, it is recommended to consider whether any such framing is needed for any given engagement. The boundaries can also be used to define exit criteria for the engagement. +* **Brand exposure:** Once the company starts interacting with and contributing to the open source software project, it will associate its brand with the project and any company developers will represent the company brand in the context. Generally speaking, the larger the contribution/engagement, the larger the brand exposure. As such, the company should assess if there are any bad will risks entailed with being associated with the open source software project. Bad will risks may also arise if the company provides poor quality contributions or if its employees misbehave in the open source software project, e.g. acting in breach of the project’s Code of Conduct. On the other hand, being associated with an open source software project in a positive way will of course carry a potential of goodwill, thereby strengthening the company brand. The decision to support an open source software project might be an opportunity for the marketing unit to provide a press release on the topic and thus strengthening the perception of the company as an open source software friendly company. ## Suitability assessment – Legal & Intellectual Property Rights (IPR) -Depending on the type of contribution and the scope thereof (see Section 1.2 above), various legal and IPR aspects may need to be considered. In short, the company needs to: - -• Ensure that it is not violating third party rights. -• Avoid non-intended exposure of its own proprietary assets. - -• Ensure compliance with relevant laws and regulations. +Depending on the type of contribution and the scope thereof (see Section 1.2 above), various legal and IPR aspects may need to be considered. In short, the company needs to: -• Observe any legal instruments required by the FOSS project in question (such as Contributor License Agreements or Developer Certificates of Origin). +* Ensure that it is not violating third party rights. +* Avoid non-intended exposure of its own proprietary assets. +* Ensure compliance with relevant laws and regulations. +* Observe any legal instruments required by the FOSS project in question (such as Contributor License Agreements or Developer Certificates of Origin). ### Third party rights A fundamental starting point when considering a contribution is that the contributing company has appropriately secured the right to do so in the first place. Any source code and corresponding documentation should be assumed to be protected by copyright unless the contribution is rudimentary to the point where it can safely be assumed to lack originality. In unclear cases, it is generally advisable to involve legal counsel before ruling out copyright as a relevant factor. - + Before making a contribution of copyright-protected material, consider the following: - -• Ensure that you know who the author(s) of the material are. -• If any part of the material was created by a third party, such as a consultant or a supplier, review the contract to ensure that the title and ownership of the copyright was passed on to your company or that you otherwise received license rights that would allow you to make the contemplated contribution. If such contract is not in place, or if the existing contract does not explicitly grant sufficient rights to make a contribution, do not proceed with the contribution until an adequate contract or contract amendment has been negotiated with the copyright holder. +* Ensure that you know who the author(s) of the material are. + +* If any part of the material was created by a third party, such as a consultant or a supplier, review the contract to ensure that the title and ownership of the copyright was passed on to your company or that you otherwise received license rights that would allow you to make the contemplated contribution. If such contract is not in place, or if the existing contract does not explicitly grant sufficient rights to make a contribution, do not proceed with the contribution until an adequate contract or contract amendment has been negotiated with the copyright holder. -• If the material has been developed independently or if it may include portions of material made by others, for instance by copying and pasting code snippets or text passages from other sources. In the latter case, it will be necessary to assess from a copyright perspective whether this use of third party sources prevents the contribution in question. +* If the material has been developed independently or if it may include portions of material made by others, for instance by copying and pasting code snippets or text passages from other sources. In the latter case, it will be necessary to assess from a copyright perspective whether this use of third party sources prevents the contribution in question. -• If the material has been developed with the support of generative AI, it may require additional considerations depending on the AI tool in question. This includes, for instance, whether the terms and conditions of the AI tool allows for such use of its output, and to which extent the output is truly generative rather than derivative from the dataset that the AI tool has been trained on. Please note that it is unlikely that material created exclusively by an AI is possible to protect by means of intellectual property rights, such as copyright. +* If the material has been developed with the support of generative AI, it may require additional considerations depending on the AI tool in question. This includes, for instance, whether the terms and conditions of the AI tool allows for such use of its output, and to which extent the output is truly generative rather than derivative from the dataset that the AI tool has been trained on. Please note that it is unlikely that material created exclusively by an AI is possible to protect by means of intellectual property rights, such as copyright. Apart from copyright, a contribution may also be subject to other third party rights. For instance: - -• It may contain trade secrets or confidential information of third parties. Be aware that a contribution to an open source project will be a public disclosure of the information in question. It is therefore important to ensure that the contribution does not breach any confidentiality obligations or otherwise misappropriate any trade secrets of others. -• The use, functionality or specific implementations of the contribution may be subject to third party patent rights. In contrast to the literal scope of copyright protection, patents protect technical inventions – products or processes, i.e. a certain functionality. As such, even if the copyright to the code contribution belongs with the contributing company, using the code can at the same time be infringing on third party patent rights if it facilitates the execution of a patent-protected invention in a specific technical context. For minor contributions (bugfixes, etc.), this is unlikely an issue, but when contributing new features to an open source software project, align with the internal IP department or an IP expert about whether to perform freedom-to-operate patent investigations before making such contributions. +* It may contain trade secrets or confidential information of third parties. Be aware that a contribution to an open source project will be a public disclosure of the information in question. It is therefore important to ensure that the contribution does not breach any confidentiality obligations or otherwise misappropriate any trade secrets of others. + +* The use, functionality or specific implementations of the contribution may be subject to third party patent rights. In contrast to the literal scope of copyright protection, patents protect technical inventions – products or processes, i.e. a certain functionality. As such, even if the copyright to the code contribution belongs with the contributing company, using the code can at the same time be infringing on third party patent rights if it facilitates the execution of a patent-protected invention in a specific technical context. For minor contributions (bugfixes, etc.), this is unlikely an issue, but when contributing new features to an open source software project, align with the internal IP department or an IP expert about whether to perform freedom-to-operate patent investigations before making such contributions. ### The legal consequence of contributing an information asset to an open source software project -Contributing to an open source software project is an act of transforming company-internal information – be it code, know-how, experience, or documentation – into an external asset shared with others. It is generally an irreversible transaction without any direct monetary reimbursement. As such, as mentioned in the beginning of this module 3, it is important from a business perspective to make a conscious decision about what to share and how. +Contributing to an open source software project is an act of transforming company-internal information – be it code, know-how, experience, or documentation – into an external asset shared with others. It is generally an irreversible transaction without any direct monetary reimbursement. As such, as mentioned in the beginning of this module 3, it is important from a business perspective to make a conscious decision about what to share and how. -From the legal perspective, the company will normally not assign or transfer its ownership of the intellectual property rights of the contributed asset. However, by making the contribution, the company will essentially pledge the asset and the corresponding intellectual property rights to become open in a manner which will significantly reduce the possibilities for the company to restrict future use of the contributed asset – except for enforcement vis-á-vis future users who do not comply with the open source software license in question. This loss of legal control should be viewed as part of the price of becoming a contributor. +From the legal perspective, the company will normally not assign or transfer its ownership of the intellectual property rights of the contributed asset. However, by making the contribution, the company will essentially pledge the asset and the corresponding intellectual property rights to become open in a manner which will significantly reduce the possibilities for the company to restrict future use of the contributed asset – except for enforcement vis-á-vis future users who do not comply with the open source software license in question. This loss of legal control should be viewed as part of the price of becoming a contributor. Open source software projects will from time to time use various legal instruments to ensure the company’s and/or developer’s commitment to the contribution. -• To begin with, the open source software project will have a license regime for outbound licensing where one or more licenses are predominantly used or required for the downstream distribution. Such license regime may be defined in the project charter (if such charter exists) or elsewhere. At the very least, there is typically one or more LICENSE files in the repository. Although most open source software licenses focus on the outbound, downstream licensing rather than how to receive contributions, some open source software licenses also include specific terms and conditions for making contributions, such as the Apache License, Version 2.0. +* To begin with, the open source software project will have a license regime for outbound licensing where one or more licenses are predominantly used or required for the downstream distribution. Such license regime may be defined in the project charter (if such charter exists) or elsewhere. At the very least, there is typically one or more LICENSE files in the repository. Although most open source software licenses focus on the outbound, downstream licensing rather than how to receive contributions, some open source software licenses also include specific terms and conditions for making contributions, such as the Apache License, Version 2.0. -• A frequently used open source software project philosophy is inbound = outbound, meaning that the project has declared (e.g. in the project charter or a CONTRIBUTIONS file) that it only accepts contributions under the same license as the outbound license. As such, making a contribution to the project will be assumed to be licensed in to the project on the same terms as it is licensed out from the project. +* A frequently used open source software project philosophy is inbound = outbound, meaning that the project has declared (e.g. in the project charter or a CONTRIBUTIONS file) that it only accepts contributions under the same license as the outbound license. As such, making a contribution to the project will be assumed to be licensed in to the project on the same terms as it is licensed out from the project. -• In order to legally solidify and secure the commitment of contributors, some open source software projects also use so-called Developer Certificates of Origin (DCO), Contributor License Agreements (CLA), or similar. +* In order to legally solidify and secure the commitment of contributors, some open source software projects also use so-called Developer Certificates of Origin (DCO), Contributor License Agreements (CLA), or similar. -• A DCO is a unilateral sign-off by the contributor certifying that it has the adequate rights to make the contribution and that it understands the public nature of the contribution (including the sign-off). Different open source software projects may use different mechanisms for recording the DCO, but the typical approach is that the sign-off is embedded in the git commits. +* A DCO is a unilateral sign-off by the contributor certifying that it has the adequate rights to make the contribution and that it understands the public nature of the contribution (including the sign-off). Different open source software projects may use different mechanisms for recording the DCO, but the typical approach is that the sign-off is embedded in the git commits. -• A CLA is an agreement between the contributor – an individual or a legal entity – and the open source software project owner. In general, the purpose of a CLA is to improve the project’s ability to rely on contributions from a contributor. Please note that a CLA may in various ways extend beyond the contribution at hand, e.g. to cover any future contributions by employees of a company or group of companies. As such, it is strongly recommended to review and understand the terms and conditions of any CLA before signing it and proceeding with contributions. +* A CLA is an agreement between the contributor – an individual or a legal entity – and the open source software project owner. In general, the purpose of a CLA is to improve the project’s ability to rely on contributions from a contributor. Please note that a CLA may in various ways extend beyond the contribution at hand, e.g. to cover any future contributions by employees of a company or group of companies. As such, it is strongly recommended to review and understand the terms and conditions of any CLA before signing it and proceeding with contributions. -• As mentioned above, most open source software projects will retrieve contributions on a license basis, and not by transfer of ownership. However, a project can of course in theory acquire the intellectual property rights (IPR) instead of licensing it. To do so, an IPR assignment agreement would have to be executed between the contributor and project owner. Please note that an assignment of the IPR in a contribution would entail a complete transfer of rights and should as such be carefully deliberated before it is accepted. +* As mentioned above, most open source software projects will retrieve contributions on a license basis, and not by transfer of ownership. However, a project can of course in theory acquire the intellectual property rights (IPR) instead of licensing it. To do so, an IPR assignment agreement would have to be executed between the contributor and project owner. Please note that an assignment of the IPR in a contribution would entail a complete transfer of rights and should as such be carefully deliberated before it is accepted. -• Before making a contribution, a company should make sure to review and understand the implications of the specific CLA, DCO or other terms and conditions applicable for the contribution. +* Before making a contribution, a company should make sure to review and understand the implications of the specific CLA, DCO or other terms and conditions applicable for the contribution. -• To which extent the contributor is legally bound to the terms and conditions set out by an open source software project depends on the circumstances in the specific case. A signed CLA will of course more solidly establish the contribution than a general inbound=outbound principle. +* To which extent the contributor is legally bound to the terms and conditions set out by an open source software project depends on the circumstances in the specific case. A signed CLA will of course more solidly establish the contribution than a general inbound=outbound principle. In summary, a contributing company should consider the following: -• Different open source software projects will have different methods of validating your contribution, ranging from implicit presumptions to requiring formal agreements. In any case, there will be a general expectation that your contribution becomes open source software. +* Different open source software projects will have different methods of validating your contribution, ranging from implicit presumptions to requiring formal agreements. In any case, there will be a general expectation that your contribution becomes open source software. -• Whether or not the contributing company is legally bound by the terms and conditions of an open source software project will depend on the circumstances in the specific case, but a general approach for a contributing company should be to avoid any ambiguity and potential conflicts in this regard. - -• If – for some reason – the contributing company wishes to make any reservations or contribute under different terms and conditions than what is established/assumed in the open source software project, it is important to be clear and explicit about such reservations. A suggestion is to reach out to the project owner or a maintainer to initiate a dialogue about a potential conditional contribution before making the contribution. +* Whether or not the contributing company is legally bound by the terms and conditions of an open source software project will depend on the circumstances in the specific case, but a general approach for a contributing company should be to avoid any ambiguity and potential conflicts in this regard. +* If – for some reason – the contributing company wishes to make any reservations or contribute under different terms and conditions than what is established/assumed in the open source software project, it is important to be clear and explicit about such reservations. A suggestion is to reach out to the project owner or a maintainer to initiate a dialogue about a potential conditional contribution before making the contribution. ### Compliance with laws and regulations -Apart from what is stated above, participation in an open source software project – depending on its nature – may trigger various regulatory considerations. This is not unique to open source software projects as such, but nevertheless important to keep in mind. -• For instance, competitor representatives may interact in steering committees or other forums of an open source software project, which entails competition/antitrust law considerations. - -• In any context where representatives from actual or potential competitors are participating, it is advisable to avoid any sharing of commercially sensitive information and to have customary mechanisms to remind and record diligence with applicable competition/antitrust law regimes. -• Larger open source software projects and/or Open Source Foundations may have their own antitrust guidelines. Many companies will also have their own policies in respect of competition law compliance. Contributors should ensure awareness of such guidelines and policies and assess whether they require any particular actions or precautions for the intended engagement. +Apart from what is stated above, participation in an open source software project – depending on its nature – may trigger various regulatory considerations. This is not unique to open source software projects as such, but nevertheless important to keep in mind. + +* For instance, competitor representatives may interact in steering committees or other forums of an open source software project, which entails competition/antitrust law considerations. -• Moreover, the technology in itself – or its distribution – may be regulated, for instance under export control regulation (although published open source software is often exempted) or specific product or technology legislation. Involve relevant experts as necessary in cases of uncertainty whether specific code or documentation can be shared in an open source software context and/or if it requires specific measures, such as BIS and NSA notifications for non-standard cryptography software. Certain technology fields may also in various jurisdictions be subject to special regulation. +* In any context where representatives from actual or potential competitors are participating, it is advisable to avoid any sharing of commercially sensitive information and to have customary mechanisms to remind and record diligence with applicable competition/antitrust law regimes. +* Larger open source software projects and/or Open Source Foundations may have their own antitrust guidelines. Many companies will also have their own policies in respect of competition law compliance. Contributors should ensure awareness of such guidelines and policies and assess whether they require any particular actions or precautions for the intended engagement. + +* Moreover, the technology in itself – or its distribution – may be regulated, for instance under export control regulation (although published open source software is often exempted) or specific product or technology legislation. Involve relevant experts as necessary in cases of uncertainty whether specific code or documentation can be shared in an open source software context and/or if it requires specific measures, such as BIS and NSA notifications for non-standard cryptography software. Certain technology fields may also in various jurisdictions be subject to special regulation. ## Creating a new open source software project -Deciding to create a new open source software project shares many of the same considerations with the choice of making major or continuous contributions to existing open source software projects. For instance, the three cornerstones are equally applicable -: -• Purpose. A defined purpose for creating the open source software project. -• Suitability. A suitability assessment from relevant perspectives, based on the purpose. +Deciding to create a new open source software project shares many of the same considerations with the choice of making major or continuous contributions to existing open source software projects. For instance, the three cornerstones are equally applicable: + +* Purpose. A defined purpose for creating the open source software project. + +* Suitability. A suitability assessment from relevant perspectives, based on the purpose. + +* Conscious decision. A conscious decision based on the above, including the allocation of adequate and suitable resources. -• Conscious decision. A conscious decision based on the above, including the allocation of adequate and suitable resources. A significant difference, however, is that the creator of a new open source software project needs to take several additional decisions to establish the project in the first place, and that the project essentially needs to be viewed as any other software development project. In other words, it needs to be planned, staffed, funded, launched, governed, and maintained over the project lifecycle. Further, the success of the project will depend on successful external community building. ### Defining the purpose of the open source software project -Similar to what is described in module 3 for contributions to existing open source software projects, it is important to have a clear purpose for creating an open source software project. Why should we create this project? -Given that it will require some effort, and that internal assets will be published under a (more or less) permissive open source software license, there should be an obvious business reason to start the project. -For instance, the reason could be to push an open standard in a software layer that drives a lot of internal development costs, but which does not as such add distinctive features to the company’s end-product. An open source software standardization effort could also be a response to a competing proprietary standard or to attempt disrupting a monopolistic market. Another scenario could be that the company has identified a business model where the open source software project is used to drive broad adoption, but there is a good potential for revenue streams connected to services relating to the open source software project. In this context, so-called ‘dual licensing’ models are getting increasingly common, where the software is simultaneously released both as open source software – typically under a strong copyleft license – and as a traditional commercial license. Further, one reason could simply be that the company lacks sufficient competence and knowledge to maintain a software asset and/or wishes to share the development and maintenance costs for it. The reason may even be altruistic, in the sense that the open source software asset holds no business value for the company but has a potential value for society (where an indirect business reason could be goodwill). Many other potential business reasons exist; the key point is that a company needs to identify at least one to proceed with the activity. -When the question “why” is answered, it will as a next step be necessary to assess the suitability in terms of needed resources, engagement, timeframe, legal and IPR, etc. Starting an open source software project also comes with a set of choices, as further outlined below. - -### Suitability and Choices -Starting an open source software project is a strategic choice. Even if it has a limited impact in relation to the overall business of the company, it is still recommended to approach it as a strategic choice compared to other available alternatives. Thus, before creating such a project, a company should ask itself: +Similar to what is described in module 3 for contributions to existing open source software projects, it is important to have a clear purpose for creating an open source software project. Why should we create this project? -• Is it aligned with our company strategy to release this asset as open source software? +Given that it will require some effort, and that internal assets will be published under a (more or less) permissive open source software license, there should be an obvious business reason to start the project. -• What will our future engagement be (in the short and long term)? +For instance, the reason could be to push an open standard in a software layer that drives a lot of internal development costs, but which does not as such add distinctive features to the company’s end-product. An open source software standardization effort could also be a response to a competing proprietary standard or to attempt disrupting a monopolistic market. Another scenario could be that the company has identified a business model where the open source software project is used to drive broad adoption, but there is a good potential for revenue streams connected to services relating to the open source software project. In this context, so-called ‘dual licensing’ models are getting increasingly common, where the software is simultaneously released both as open source software – typically under a strong copyleft license – and as a traditional commercial license. Further, one reason could simply be that the company lacks sufficient competence and knowledge to maintain a software asset and/or wishes to share the development and maintenance costs for it. The reason may even be altruistic, in the sense that the open source software asset holds no business value for the company but has a potential value for society (where an indirect business reason could be goodwill). Many other potential business reasons exist; the key point is that a company needs to identify at least one to proceed with the activity. -• Will the potential benefits warrant the level of engagement (in the short and long term)? +When the question “why” is answered, it will as a next step be necessary to assess the suitability in terms of needed resources, engagement, timeframe, legal and IPR, etc. Starting an open source software project also comes with a set of choices, as further outlined below. -• What is the expected outcome, and how can that be secured? +### Suitability and Choices -• Are there any risks connected to the activity? +Starting an open source software project is a strategic choice. Even if it has a limited impact in relation to the overall business of the company, it is still recommended to approach it as a strategic choice compared to other available alternatives. Thus, before creating such a project, a company should ask itself: -• Are there any other open source software projects attempting to solve the same problem? If so, why create a new project instead of contributing to an existing project? +* Is it aligned with our company strategy to release this asset as open source software? +* What will our future engagement be (in the short and long term)? +* Will the potential benefits warrant the level of engagement (in the short and long term)? +* What is the expected outcome, and how can that be secured? +* Are there any risks connected to the activity? +* Are there any other open source software projects attempting to solve the same problem? If so, why create a new project instead of contributing to an existing project? The suitability assessment set out in module 3.1 is generally applicable to the creation of an open source software project as well. Below follows a few examples of additional considerations relating to the creation of open source software projects. -**• Governance model:** As mentioned in see module 3, open source software projects can be governed in different ways. It is essential to set up a governance model that will support the purpose of the project. As mentioned, projects controlled by a single company typically lack community-based governance fora such as Technical Steering Committees and the company appoints Committer roles to its employees to gatekeep all code going into the codebase. The benefit of this is of course a strong control position, but such a control position may also deter others from engaging in the project. An opposite extreme would be to “donate” the software asset to a neutral party, typically an existing Open Source Foundation (or a new foundation created for the purpose). A hybrid model can also be to have a phased approach, where the company retains initial control but gradually moves over to a meritocracy-based governance model. Depending on the size of the initiative, it could on the one hand be of such monumental scope that it requires some kind of umbrella organization with its own governance (and e.g. specific committees to handle technical sub-streams), and it could on the other hand be sufficient to have a very lean setup for a simple niche open source software library. Many variants exist, each with pros and cons. The bottom line is that the company should thoroughly consider which governance model fits best for the specific project. +* **Governance model:** As mentioned in see module 3, open source software projects can be governed in different ways. It is essential to set up a governance model that will support the purpose of the project. As mentioned, projects controlled by a single company typically lack community-based governance fora such as Technical Steering Committees and the company appoints Committer roles to its employees to gatekeep all code going into the codebase. The benefit of this is of course a strong control position, but such a control position may also deter others from engaging in the project. An opposite extreme would be to “donate” the software asset to a neutral party, typically an existing Open Source Foundation (or a new foundation created for the purpose). A hybrid model can also be to have a phased approach, where the company retains initial control but gradually moves over to a meritocracy-based governance model. Depending on the size of the initiative, it could on the one hand be of such monumental scope that it requires some kind of umbrella organization with its own governance (and e.g. specific committees to handle technical sub-streams), and it could on the other hand be sufficient to have a very lean setup for a simple niche open source software library. Many variants exist, each with pros and cons. The bottom line is that the company should thoroughly consider which governance model fits best for the specific project. -**• Communication:** Communication is an important part of launching – as well as maintaining – a successful open source software project. Roughly speaking, it needs to serve the high-level marketing purpose of attracting a strong community, as well as the detailed purpose of ensuring that all contributors understand the rules of engagement in the project. As such, consider which communication channels to use, how to clearly reach out with the project’s vision and problem statement (and the benefits of its purported solution), as well as more detailed day-to-day information. Consider engaging internal or external marketing expertise for larger open source software projects. +* **Communication:** Communication is an important part of launching – as well as maintaining – a successful open source software project. Roughly speaking, it needs to serve the high-level marketing purpose of attracting a strong community, as well as the detailed purpose of ensuring that all contributors understand the rules of engagement in the project. As such, consider which communication channels to use, how to clearly reach out with the project’s vision and problem statement (and the benefits of its purported solution), as well as more detailed day-to-day information. Consider engaging internal or external marketing expertise for larger open source software projects. -**• Timing:** The timing of launching the open source software project is important from several perspectives. As a first example, the maturity of the asset itself is of course a factor – it will be significantly harder to gain traction for an unmaterialized idea compared to a working software application. Waiting too long, on the other hand, will waste internal resources on efforts which could potentially have been shared with others in open collaboration. If the purpose is standardization, there will always be a risk that other de facto standards grow strong while the company prepares to publish its own initiative. Once again, it will be important to find a good balance between speed and readiness to achieve the purpose, but as a general notion, the company should at least make sure to go through and make necessary preparations for the items proposed in this see module 3, as well as perform relevant technical reviews of the open source software asset (see module 3), before launching the project. +* **Timing:** The timing of launching the open source software project is important from several perspectives. As a first example, the maturity of the asset itself is of course a factor – it will be significantly harder to gain traction for an unmaterialized idea compared to a working software application. Waiting too long, on the other hand, will waste internal resources on efforts which could potentially have been shared with others in open collaboration. If the purpose is standardization, there will always be a risk that other de facto standards grow strong while the company prepares to publish its own initiative. Once again, it will be important to find a good balance between speed and readiness to achieve the purpose, but as a general notion, the company should at least make sure to go through and make necessary preparations for the items proposed in this see module 3, as well as perform relevant technical reviews of the open source software asset (see module 3), before launching the project. -**• Choice of repository:** The choice to create an open source software project will also come with a choice of how to publish and host the software in question. The company should make an educated choice of repository to keep the code safe and version-controlled, and which facilitates collaboration and enables statistics and analysis as necessary. If in doubt, it is likely a good idea to use one of the reputable and well-known repository services on the market. +* **Choice of repository:** The choice to create an open source software project will also come with a choice of how to publish and host the software in question. The company should make an educated choice of repository to keep the code safe and version-controlled, and which facilitates collaboration and enables statistics and analysis as necessary. If in doubt, it is likely a good idea to use one of the reputable and well-known repository services on the market. ### Suitability and Choices – Legal & Intellectual Property Rights (IPR) -When starting an open source software project, various legal and IPR aspects will need to be considered. In short, the company needs to: -• Ensure that it is not violating third party rights. - -• Ensure that contributions and contributors are not violating third party rights. +When starting an open source software project, various legal and IPR aspects will need to be considered. In short, the company needs to: -• Ensure compliance with relevant laws and regulations. +* Ensure that it is not violating third party rights. +* Ensure that contributions and contributors are not violating third party rights. +* Ensure compliance with relevant laws and regulations. +* Choose relevant legal instruments (e.g. the open source software license) and policies for the project. -• Choose relevant legal instruments (e.g. the open source software license) and policies for the project. +#### Third party rights -**Third party rights -** The legal and IPR suitability assessment set out in module 3.1 is generally applicable to assets that the company itself puts into the open source software project, from the start as well as thereafter. In the following, additional considerations relating to the creation of open source software projects have been added. -**• Choice of license:** The choice of license for the downstream distribution is highly connected to the goal of the open source software project. If it is crucial to drive continuous openness, it is an argument for choosing a copyleft license. If broad adoption by commercial downstream implementers and re-distributors is key, however, it is an argument for a non-copyleft license. If the software is created in a heavily patented landscape, it may be worth choosing a license with explicit patent language (patent license/non-assertion, etc.) rather than relying on licenses where patents are not mentioned (i.e. where the patent license is at best implied). If the software is intended to be combined with other open source software, make sure that the selected license is compatible (or if suitable identical) with the other open source software project license. In theory, a company can draft its own tailored license for the published software. However, this has the drawback of using a license that is not yet recognized by reputable institutions such as the Open Source Initiative, which in turn increases the threshold to establish general trust in the license and may make it harder to build a community. As such, the alternative of drafting a unique license is seldomly worth the effort (and lawyer hours), and should primarily be considered for strategic and large open source software projects with an equally strong branding agenda where the license can be branded as part of the initiative. Consult legal expertise if necessary to make a good choice in this respect. +* **Choice of license:** The choice of license for the downstream distribution is highly connected to the goal of the open source software project. If it is crucial to drive continuous openness, it is an argument for choosing a copyleft license. If broad adoption by commercial downstream implementers and re-distributors is key, however, it is an argument for a non-copyleft license. If the software is created in a heavily patented landscape, it may be worth choosing a license with explicit patent language (patent license/non-assertion, etc.) rather than relying on licenses where patents are not mentioned (i.e. where the patent license is at best implied). If the software is intended to be combined with other open source software, make sure that the selected license is compatible (or if suitable identical) with the other open source software project license. In theory, a company can draft its own tailored license for the published software. However, this has the drawback of using a license that is not yet recognized by reputable institutions such as the Open Source Initiative, which in turn increases the threshold to establish general trust in the license and may make it harder to build a community. As such, the alternative of drafting a unique license is seldomly worth the effort (and lawyer hours), and should primarily be considered for strategic and large open source software projects with an equally strong branding agenda where the license can be branded as part of the initiative. Consult legal expertise if necessary to make a good choice in this respect. + +* **Choice of contribution model:** The company needs to decide whether or not to use a CLA, DCO or other legal instrument to record inbound contributions of if it should simply make an inbound = outbound statement or similar. Like other decisions in this area, choices that increase the company’s control may at the same time deter collaborators and contributors from engaging in the open source software project. In any case, it is not advisable to leave it completely open for contributors to set terms and conditions for their contributions – that will eventually create chaos in the project and hamper both downstream and contributor interest. In conclusion, it is recommended to clearly communicate a contribution model to contributors, irrespective of whether it leans towards maximizing control (e.g. a CLA) or if the main driver is simplicity (e.g. an inbound=outbound statement). -**• Choice of contribution model:** The company needs to decide whether or not to use a CLA, DCO or other legal instrument to record inbound contributions of if it should simply make an inbound = outbound statement or similar. Like other decisions in this area, choices that increase the company’s control may at the same time deter collaborators and contributors from engaging in the open source software project. In any case, it is not advisable to leave it completely open for contributors to set terms and conditions for their contributions – that will eventually create chaos in the project and hamper both downstream and contributor interest. In conclusion, it is recommended to clearly communicate a contribution model to contributors, irrespective of whether it leans towards maximizing control (e.g. a CLA) or if the main driver is simplicity (e.g. an inbound=outbound statement). - -**• Antitrust Guidelines:** As the facilitator of an open collaboration forum, the company may potentially also be inviting actual or potential competitors to participate in the co-creation of the open source software asset. This section will not attempt to exhaustively describe such legislation, but it is important to note that certain interactions and agreements between competitors are prohibited, in particular the creation of cartels. In certain jurisdictions, liability may extend also to a coordinator of a cartel between other parties. In light of this, it is generally advisable to establish an antitrust guideline for any open source software project where competitors may interact, and – needless to say – to comply with the said guideline and applicable antitrust and competition laws. +* **Antitrust Guidelines:** As the facilitator of an open collaboration forum, the company may potentially also be inviting actual or potential competitors to participate in the co-creation of the open source software asset. This section will not attempt to exhaustively describe such legislation, but it is important to note that certain interactions and agreements between competitors are prohibited, in particular the creation of cartels. In certain jurisdictions, liability may extend also to a coordinator of a cartel between other parties. In light of this, it is generally advisable to establish an antitrust guideline for any open source software project where competitors may interact, and – needless to say – to comply with the said guideline and applicable antitrust and competition laws. -**• Data Privacy:** Please note that by governing an open source software project, the company may be deemed a data controller responsible for the processing of personal data under the GDPR and other data privacy laws. As such, make sure to establish customary privacy notices, cookie consent forms and other measures to ensure compliance with such laws. +* **Data Privacy:** Please note that by governing an open source software project, the company may be deemed a data controller responsible for the processing of personal data under the GDPR and other data privacy laws. As such, make sure to establish customary privacy notices, cookie consent forms and other measures to ensure compliance with such laws. ## Operational aspects of maintaining engagement in an open source software project @@ -213,100 +204,39 @@ Maintaining the engagement, after the company decision to continuously engage wi ### Evaluating the engagement versus the exit criteria Evaluating the engagement with an open source software project is a recurring process. It requires consideration whether the initial motivations remain valid and if the engagement is achieving its intended goals. -Companies may over time find reasons to reconsider or end their participation in open source projects. It is important to establish clear exit criteria and maintain open communication with the community to preserve good relationships and minimize disruptions. These factors are often related to a company's goals, brand image, product development, or sustainability objectives. If these goals are no longer met or aligned with the company's strategic direction, it may decide to stop contributing. -Reasons for a company to decide to disengage with an open source community might be due to changed company internal reasons, project related reasons or just other external factors outside of the project. Examples of exit criteria might include the following: -• The company's original purpose for contributing is no longer relevant. - -• The project's focus has shifted and no longer matches defined purpose. - -• Another project aligns better with the company's objectives. - -Other exit criteria examples: -• The company's strategic goals have changed significantly. -• The project's expected outcomes are no longer achievable. - -• The company’s expectation on the result of the engagement is not met. - -• The company's contributions are not used effectively. - -• The company's expertise in the project's area have diminished. - -• The company ability to contribute has decreased significantly. - -• The company cannot finance the necessary commitments and resources. - -• Risk for damage on brand image. - -• Legal risks or conflicts of interest arise. - -• Community engagement is low, impacting the project's sustainability. - -• Negative behaviors within the community hinder collaboration. - -By defining exit criteria and engaging with the community, companies can responsibly manage their involvement in open source projects. These criteria should be periodically reviewed and communicated to both within the company and to the community. This approach maintains transparency, ensures positive relationships, and facilitates smooth transitions when adjustments to contributions or participation are necessary. - -Ref: [Learning designer notes: Must be moved from Github file] -https://www.linuxfoundation.org/resources/open-source-guides/winding-down-an-open-source-project - -### Securing continued engagement -One part of securing a continued engagement by the company, if the evaluation to continue the engagement is positive, is to make sure the involved resources have the right competence and motivation to continue in combination with a reasonable opportunity to do so in terms of dedicated time and workload. - -Another aspect of securing a continued engagement may be to assign additional resource(s) and competence(s) to supporting the appointed resource(s) for competence redundancy and future individual independency. - -Appointing someone to engage in a community is not only an investment in the community but also in the selected person. Creating internal company visibility of the engagement may also create increased attraction and motivation. - -Other opportunities for the company to secure a continued engagement in the community may involve activities like hosting or sponsoring events for the community to meet and network as well as give presentations of the project. Such events can also serve as marketing opportunities for the company. - -### Evaluating the engagement versus the exit criteria - -Evaluating the engagement with a FOSS project is a recurring process. It requires consideration whether the initial motivations remain valid and if the engagement is achieving its intended goals. - -Companies may over time find reasons to reconsider or end their participation in open-source projects. It is important to establish clear exit criteria and maintain open communication with the community to preserve good relationships and minimize disruptions. These factors are often related to a company's goals, brand image, product development, or sustainability objectives. If these goals are no longer met or aligned with the company's strategic direction, it may decide to stop contributing. +Companies may over time find reasons to reconsider or end their participation in open source projects. It is important to establish clear exit criteria and maintain open communication with the community to preserve good relationships and minimize disruptions. These factors are often related to a company's goals, brand image, product development, or sustainability objectives. If these goals are no longer met or aligned with the company's strategic direction, it may decide to stop contributing. Reasons for a company to decide to disengage with an open source community might be due to changed company internal reasons, project related reasons or just other external factors outside of the project. Examples of exit criteria might include the following: -• The company's original purpose for contributing is no longer relevant. - -• The project's focus has shifted and no longer matches defined purpose. -• Another project aligns better with the company's objectives. +* The company's original purpose for contributing is no longer relevant. +* The project's focus has shifted and no longer matches defined purpose. +* Another project aligns better with the company's objectives. Other exit criteria examples: -• The company's strategic goals have changed significantly. - -• The project's expected outcomes are no longer achievable. - -• The company’s expectation on the result of the engagement is not met. - -• The company's contributions are not used effectively. - -• The company's expertise in the project's area have diminished. - -• The company ability to contribute has decreased significantly. -• The company cannot finance the necessary commitments and resources. +* The company's strategic goals have changed significantly. +* The project's expected outcomes are no longer achievable. +* The company’s expectation on the result of the engagement is not met. +* The company's contributions are not used effectively. +* The company's expertise in the project's area have diminished. +* The company ability to contribute has decreased significantly. +* The company cannot finance the necessary commitments and resources. +* Risk for damage on brand image. +* Legal risks or conflicts of interest arise. +* Community engagement is low, impacting the project's sustainability. +* Negative behaviors within the community hinder collaboration. -• Risk for damage on brand image. - -• Legal risks or conflicts of interest arise. - -• Community engagement is low, impacting the project's sustainability. - -• Negative behaviors within the community hinder collaboration. - -By defining exit criteria and engaging with the community, companies can responsibly manage their involvement in open-source projects. These criteria should be periodically reviewed and communicated to both within the company and to the community. This approach maintains transparency, ensures positive relationships, and facilitates smooth transitions when adjustments to contributions or participation are necessary. - -Ref: [Learning designer notes: Must be moved from Github file] -https://www.linuxfoundation.org/resources/open-source-guides/winding-down-an-open-source-project +By defining exit criteria and engaging with the community, companies can responsibly manage their involvement in open source projects. These criteria should be periodically reviewed and communicated to both within the company and to the community. This approach maintains transparency, ensures positive relationships, and facilitates smooth transitions when adjustments to contributions or participation are necessary[^lf-wind-down-project]. +[^lf-wind-down-project]: [Winding Down an Open Source Project](https://www.linuxfoundation.org/resources/open-source-guides/winding-down-an-open-source-project) ### Securing continued engagement + One part of securing a continued engagement by the company, if the evaluation to continue the engagement is positive, is to make sure the involved resources have the right competence and motivation to continue in combination with a reasonable opportunity to do so in terms of dedicated time and workload. -Another aspect of securing a continued engagement may be to assign additional resource(s) and competence(s) to supporting the appointed resource(s) for competence redundancy and future individual independency. +Another aspect of securing a continued engagement may be to assign additional resource(s) and competence(s) to supporting the appointed resource(s) for competence redundancy and future individual independency. Appointing someone to engage in a community is not only an investment in the community but also in the selected person. Creating internal company visibility of the engagement may also create increased attraction and motivation. -Other opportunities for the company to secure a continued engagement in the community may involve activities like hosting or sponsoring events for the community to meet and network as well as give presentations of the project. Such events can also serve as marketing opportunities for the company. - - +Other opportunities for the company to secure a continued engagement in the community may involve activities like hosting or sponsoring events for the community to meet and network as well as give presentations of the project. Such events can also serve as marketing opportunities for the company. diff --git a/Contribution-4-Ind.md b/Contribution-4-Ind.md index c3349ce..bd375d6 100644 --- a/Contribution-4-Ind.md +++ b/Contribution-4-Ind.md @@ -9,70 +9,90 @@ permalink: /Contribution-4-Ind ## Engaging in an open source software project as a company employee ### Why be a contributor? Personal benefits of being a contributor + Contributing to open source software development can be a rewarding and motivating endeavor, offering a lot of reasons to get involved as an employee. It is worth noting that these motivating factors align with those that drive other individuals and organizations to contribute to open source initiatives, as described in Module 2. From the developer's perspective, the commitment needed for engaging in open source contributions can vary. A general recommendation is that a developer should commit at a level where he or she has sufficient time to understand the issue, write code, and engage with the community while at the same time remaining flexible enough to manage other commitments and ensure a healthy work-life balance, (LogicaBeans, 2023) and (Wearedevelopers, 2022). -Open source development can serve as a good platform for personal growth, (Nyakundi, 2023). Through contributions, a developer gains hands-on experience, collaborates with experienced developers, and experiments with the latest technologies, all of which enhance their skill sets and broaden their horizons. This platform allows developers to update their knowledge and skills regularly, offering a challenging but rewarding learning process. +Open source development can serve as a good platform for personal growth, (Nyakundi, 2023). Through contributions, a developer gains hands-on experience, collaborates with experienced developers, and experiments with the latest technologies, all of which enhance their skill sets and broaden their horizons. This platform allows developers to update their knowledge and skills regularly, offering a challenging but rewarding learning process. When engaging in open source projects, developers get the opportunity to connect with professionals, make friends, and even find mentors who can provide guidance and support in your career. By navigating social dynamics effectively, developers build relationships that can contribute to personal and professional growth. Also, this sense of belonging and team spirit within an open source community, is a powerful motivator. -Open source contributions can enhance a developer’s professional portfolio, making the developer more attractive within the company as well as externally. These contributions highlight technical skills, commitment to continuous learning, and the ability to effectively collaborate within a larger and diverse community. Many companies value open source experience as it reflects developer’s dedication and competence. +Open source contributions can enhance a developer’s professional portfolio, making the developer more attractive within the company as well as externally. These contributions highlight technical skills, commitment to continuous learning, and the ability to effectively collaborate within a larger and diverse community. Many companies value open source experience as it reflects developer’s dedication and competence. Participating in an open source project can provide a sense of giving back to the community that has enriched developer skills and knowledge. Sharing expertise and mentoring others is a way to serve the community while simultaneously expanding the developer’s perspective. Most open source projects often address real-world problems, making the developer’s contributions directly impactful. Whether a developer adds a new feature, fixes a bug, or improves documentation, their contributions have the potential to make a difference. As developers witness their contributions being used by others, including their own company, they might gain a sense of achievement and satisfaction, knowing that their efforts benefit not only their team and company but also the wider community. ### Important skill sets + The open source world is vast with diverse range of projects that require various skills and expertise. People from all backgrounds participate, and open source communities usually welcome all suitable skills, which help build and improve their projects. Whether the involvement is minimal or substantial, the contribution will be valued and appreciated by the community. However, when companies consider appointing an employee to contribute to open source projects, certain skills and expertise can be more efficient than others. The specific set of skills required depends on what to achieve, the company’s strategic goal, and the available role. + The core skills and knowledge open source software projects often asks for are: -**Technical skills** +#### Technical skills -- Knowledge of version control systems, such as Git for collaboration and tracking changes. -- Knowledge of the release process, from idea and feature requests, coding, testing, and deployment, including tracking, versioning, and changelogs. -- Knowledge of syntax, semantics, data structures and algorithms of the programming languages used in the project. -- Familiarity with the advantages and disadvantages of different languages and technologies. -- Knowledge of open source development tools, libraries, and frameworks and how to integrate them. -- Ability to follow coding standards and best practices. -- Skills in designing user interfaces that are responsive, intuitive, and user-friendly. -- Knowledge of data modelling and database design. -- Skills in cybersecurity methodologies, such as threat and vulnerability assessment and penetration testing. -- Skills in testing methodologies, test and bug reporting and software requirements. -- Analytical problem-solving skills. -- Knowledge of open source licenses and company IP. -- Field-specific technical and business skills. +* Knowledge of version control systems, such as Git for collaboration and tracking changes. +* Knowledge of the release process, from idea and feature requests, coding, testing, and deployment, including tracking, versioning, and changelogs. +* Knowledge of syntax, semantics, data structures and algorithms of the programming languages used in the project. +* Familiarity with the advantages and disadvantages of different languages and technologies. +* Knowledge of open source development tools, libraries, and frameworks and how to integrate them. +* Ability to follow coding standards and best practices. +* Skills in designing user interfaces that are responsive, intuitive, and user-friendly. +* Knowledge of data modelling and database design. +* Skills in cybersecurity methodologies, such as threat and vulnerability assessment and penetration testing. +* Skills in testing methodologies, test and bug reporting and software requirements. +* Analytical problem-solving skills. +* Knowledge of open source licenses and company IP. +* Field-specific technical and business skills. -**Soft Skills** +#### Soft Skills Besides technical skills, open source projects always need and benefit from: -- Effective collaboration and communication skills. -- Proficient writing skills to create clear, concise, and informative documentation and provide guidance. -- Ability to view and document from the user’s perspective. -- Project management skills to oversee software development and maintenance. -- Leadership skills to foster a sense of inclusive community with positive engagement and collaboration. + +* Effective collaboration and communication skills. +* Proficient writing skills to create clear, concise, and informative documentation and provide guidance. +* Ability to view and document from the user’s perspective. +* Project management skills to oversee software development and maintenance. +* Leadership skills to foster a sense of inclusive community with positive engagement and collaboration. + The set of skills outlined above serves as a foundation for contributing to open source initiatives but is not exhaustive. The list of skills can expand for more complex projects or made more precise for smaller ones. Specific requirements depend on the project's complexity, type, and the role. For instance, the role maintainer should be excellent in soft skills and release management, while the role contributor might not need to be as proficient in these areas. Precise skill sets, and proficiency levels should be tailored considering the project objectives and the company’s strategic goals. ### Ethical Responsibilities + Anyone representing a company as a professional in the open source software community are presented with unique opportunities, but also entrusted with significant responsibilities. That employee becomes part of the company’s branding, representing its values and commitment to collaboration, innovation, and excellence in every interaction with the open source community. It is essential to not just develop the technical expertise but have strong ethical mindset that is aligned with the specific demands and the subtle distinction of the role. Understanding and executing these responsibilities are of greatest importance when participating in open source software initiatives. **Key responsibilities and best practices:** As contributing employee, it is crucial to -- Understand company policies: Read and understand the company's code of conduct and its policy on open source contributions. Ensure staying within them and secure the necessary approvals to contribute to the project. Keep in mind that the employee is responsible for his/her conduct and should always act with the company's principles and values in mind. In situations where the right course of action is not clear, the employee should not hesitate to contact and consult the company’s support functions. As a general principle, if something seems unethical or improper, it probably is. -- Build legal and IP skills: Be knowledgeable about open source licenses, contributor license agreements (CLA), and developer certificate of origin (DCO) to ensure compliance and avoid legal pitfalls. Protect company IP and ensure not to share proprietary or otherwise confidential company information, see Chapter 3. -- Respect community norms: Each community has its own culture, norms, guidelines, agreements (CLA or DCO) and codes of conduct, see Chapter 3. Understand and respect these rules and guidelines, including contribution guidelines. Contribute in a manner that is in harmony with the community's culture. Ensure that these expectations are in line with the company's policies and code of conduct. -- Be honest and sincere: Be transparent with company affiliation when contributing to open source projects. Identify and disclose any potential conflicts of interest. Always act ethically and contribute with integrity. -- Understand the objectives: Grasp the company’s overall strategic objectives and the project’s specific goals. Clearly understand the reasons for the company involvement in the open source software project, and ensure that any actions and contributions align with these objectives and the company’s broader mission, see Chapter 2. -- Keep high standards: Maintain the quality and professionalism expected of the company, including excellence in coding, documentation, and communication. Represent the company in a professional manner in all interactions within the community. -- Contribute meaningfully: Read through the project documentations, including issues trackers and learn from past discussions and ensure understanding of the community's needs, priorities, interests, and way of working. Prioritize features and issues that align with the company's interests and contribute to them. Document and explain why the contributions are important and valuable to the project and for the use cases. -- Stay updated: Open-source projects evolve rapidly. Stay engaged and keep up with the latest updates and trends in both technologies used and the business industry. Cultivate a curious mindset and develop technical and communication skills. -- Collaborate: Work closely with internal teams to harness collective expertise and be efficient. Learn how the project members communicate, and participate in community discussions, forums, mailing lists, and building relationships. Build and maintain relationships among community members, company employees, and other technical leaders within software development. -- Cultivate community spirit: Embrace a positive and friendly attitude towards community members and company employees. Never disrespect or discriminate but foster an inclusive environment. Being nice and welcoming other contributors helps to build a supportive and collaborative environment. -- Have patience and empathy: Be patient and understand that responses and deliveries could take time and respect that different contributors have different schedules and responsibilities. -- Value feedback: Listen to and learn from others. Be open to feedback and show willingness to change if necessary. -- Be firm: Advocate confidently and politely for what is right for the project and the company. People often demonstrate a greater capacity for understanding when approached with respect and provided well-reasoned arguments. -- Practice a healthy work-life balance: Schedule and take regular min-breaks throughout the working day. Invest in personal time, be active and make time for what matters. +* Understand company policies: Read and understand the company's code of conduct and its policy on open source contributions. Ensure staying within them and secure the necessary approvals to contribute to the project. Keep in mind that the employee is responsible for his/her conduct and should always act with the company's principles and values in mind. In situations where the right course of action is not clear, the employee should not hesitate to contact and consult the company’s support functions. As a general principle, if something seems unethical or improper, it probably is. + +* Build legal and IP skills: Be knowledgeable about open source licenses, contributor license agreements (CLA), and developer certificate of origin (DCO) to ensure compliance and avoid legal pitfalls. Protect company IP and ensure not to share proprietary or otherwise confidential company information, see Chapter 3. + +* Respect community norms: Each community has its own culture, norms, guidelines, agreements (CLA or DCO) and codes of conduct, see Chapter 3. Understand and respect these rules and guidelines, including contribution guidelines. Contribute in a manner that is in harmony with the community's culture. Ensure that these expectations are in line with the company's policies and code of conduct. + +* Be honest and sincere: Be transparent with company affiliation when contributing to open source projects. Identify and disclose any potential conflicts of interest. Always act ethically and contribute with integrity. + +* Understand the objectives: Grasp the company’s overall strategic objectives and the project’s specific goals. Clearly understand the reasons for the company involvement in the open source software project, and ensure that any actions and contributions align with these objectives and the company’s broader mission, see Chapter 2. + +* Keep high standards: Maintain the quality and professionalism expected of the company, including excellence in coding, documentation, and communication. Represent the company in a professional manner in all interactions within the community. + +* Contribute meaningfully: Read through the project documentations, including issues trackers and learn from past discussions and ensure understanding of the community's needs, priorities, interests, and way of working. Prioritize features and issues that align with the company's interests and contribute to them. Document and explain why the contributions are important and valuable to the project and for the use cases. + +* Stay updated: Open-source projects evolve rapidly. Stay engaged and keep up with the latest updates and trends in both technologies used and the business industry. Cultivate a curious mindset and develop technical and communication skills. + +* Collaborate: Work closely with internal teams to harness collective expertise and be efficient. Learn how the project members communicate, and participate in community discussions, forums, mailing lists, and building relationships. Build and maintain relationships among community members, company employees, and other technical leaders within software development. + +* Cultivate community spirit: Embrace a positive and friendly attitude towards community members and company employees. Never disrespect or discriminate but foster an inclusive environment. Being nice and welcoming other contributors helps to build a supportive and collaborative environment. + +* Have patience and empathy: Be patient and understand that responses and deliveries could take time and respect that different contributors have different schedules and responsibilities. + +* Value feedback: Listen to and learn from others. Be open to feedback and show willingness to change if necessary. + +* Be firm: Advocate confidently and politely for what is right for the project and the company. People often demonstrate a greater capacity for understanding when approached with respect and provided well-reasoned arguments. + +* Practice a healthy work-life balance: Schedule and take regular min-breaks throughout the working day. Invest in personal time, be active and make time for what matters. While this list provides key principles regarding responsibilities and ethical considerations expected by an employee contributing to open source software projects, it is not exhaustive. In addition, the outlined principles can be adapted to suit various roles within open software contribution, when developing role-specific descriptions. -Embracing these responsibilities cultivates ethical professionalism, ensures project’s sustainability, and safe-guards community integrity. It can also elevate company image and paves the way for the engineer’s career success. This not only benefits the individual, but the entire open source software ecosystem. + +Embracing these responsibilities cultivates ethical professionalism, ensures project’s sustainability, and safe-guards community integrity. It can also elevate company image and paves the way for the engineer’s career success. This not only benefits the individual, but the entire open source software ecosystem.