From 8f250c99d08d4d6f253536dc72fd3d300b11503a Mon Sep 17 00:00:00 2001 From: Georg Kunz Date: Tue, 5 Mar 2024 09:01:38 +0100 Subject: [PATCH] Adding links back to contribution documents (#13) Adding the links back now that we can ensure that they open in a new tab. --- Contribution-1-3-Ind.md | 4 +++- Contribution-1-4-Ind.md | 6 +++++- Contribution-4-Ind.md | 28 ++++++++++++++-------------- Contributions-3-2-Ind.md | 30 +++++++++++++++++++++++------- Contributions-3-3-Ind.md | 8 ++++++-- 5 files changed, 51 insertions(+), 25 deletions(-) diff --git a/Contribution-1-3-Ind.md b/Contribution-1-3-Ind.md index 48f726b..f1eeb23 100644 --- a/Contribution-1-3-Ind.md +++ b/Contribution-1-3-Ind.md @@ -13,6 +13,8 @@ It is important for everybody who engages in the open source ecosystem to unders ![image](https://github.com/ExpertLearningLab/foss-learning/assets/126161450/18a93818-b7a2-49b1-a219-dfe38d0d3697) 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. +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[^lf-census-ii]. + +[^lf-census-ii]: [Census II of Free and Open Source Software — Application Libraries](https://www.linuxfoundation.org/research/census-ii-of-free-and-open-source-software-application-libraries){:target="_blank"} ![image](https://github.com/ExpertLearningLab/foss-learning/assets/126161450/bf69b10c-07bd-47dd-a770-b325c920e5eb) diff --git a/Contribution-1-4-Ind.md b/Contribution-1-4-Ind.md index cf7efe5..d88bbdd 100644 --- a/Contribution-1-4-Ind.md +++ b/Contribution-1-4-Ind.md @@ -10,7 +10,11 @@ permalink: /Contributions-1-4-Ind 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[^log4j] or openssl[^openssl]. + +[^log4j]: [Log4j project team](https://logging.apache.org/log4j/2.x/team.html){:target="_blank"} + +[^openssl]: [OpenSSL](https://www.openssl.org/about.html){:target="_blank"} 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. diff --git a/Contribution-4-Ind.md b/Contribution-4-Ind.md index bd375d6..3f360eb 100644 --- a/Contribution-4-Ind.md +++ b/Contribution-4-Ind.md @@ -11,13 +11,13 @@ permalink: /Contribution-4-Ind ### 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). +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](https://www.linkedin.com/pulse/promote-work-life-balance-software-developers-logicabeans){:target="_blank"}, (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. 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](https://medium.com/@jaybharadiya/6-benefits-of-contributing-to-open-source-projects-in-the-software-industry-562ea3f5abf6){:target="_blank"}, 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. @@ -27,7 +27,7 @@ Most open source projects often address real-world problems, making the develope 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: +The [core skills and knowledge](https://medium.com/quick-code/essential-skills-that-every-open-source-developer-needs-d37ac668faf8){:target="_blank"} open source software projects often asks for are: #### Technical skills @@ -49,7 +49,7 @@ The core skills and knowledge open source software projects often asks for are: Besides technical skills, open source projects always need and benefit from: -* Effective collaboration and communication skills. +* [Effective collaboration and communication skills](https://ca.indeed.com/career-advice/career-development/collaboration-skills){:target="_blank"}. * 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. @@ -69,29 +69,29 @@ As contributing employee, it is crucial to * 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. +* [Respect community norms](https://chrisholdgraf.com/blog/2020/organizations-help-oss-guide/){:target="_blank"}{:target="_blank"}: 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. +* [Keep high standards](https://architectak.medium.com/a-guide-to-building-a-strong-open-source-portfolio-as-a-software-engineer-cfa8fd429eb4){:target="_blank"}: 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. +* [Contribute meaningfully](https://developer.mozilla.org/en-US/docs/MDN/Community/Open_source_etiquette){:target="_blank"}: 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. +* [Stay updated](https://architectak.medium.com/a-guide-to-building-a-strong-open-source-portfolio-as-a-software-engineer-cfa8fd429eb4){:target="_blank"}: 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. +* [Collaborate](https://ca.indeed.com/career-advice/career-development/collaboration-skills){:target="_blank"}: 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. +* [Cultivate community spirit](https://www.freecodecamp.org/news/practical-skills-for-open-source-maintainers/){:target="_blank"}: 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. +* [Have patience and empathy](https://www.freecodecamp.org/news/practical-skills-for-open-source-maintainers/){:target="_blank"}: 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. +* [Value feedback](https://www.freecodecamp.org/news/practical-skills-for-open-source-maintainers/){:target="_blank"}: 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. +* [Be firm](https://www.freecodecamp.org/news/practical-skills-for-open-source-maintainers/){:target="_blank"}: 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. +* Practice a [healthy work-life balance](https://www.linkedin.com/pulse/promote-work-life-balance-software-developers-logicabeans){:target="_blank"}: 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. diff --git a/Contributions-3-2-Ind.md b/Contributions-3-2-Ind.md index 194cd22..bc14075 100644 --- a/Contributions-3-2-Ind.md +++ b/Contributions-3-2-Ind.md @@ -35,7 +35,9 @@ Depending on the type of contribution and the scope thereof (see Section 1.2 abo ### 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. +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[^copyright]. In unclear cases, it is generally advisable to involve legal counsel before ruling out copyright as a relevant factor. + +[^copyright]: Copyright is automatically granted to the author of a literary or artistic work (in this case, source code and documentation) upon the creation of such work. In a business context, the copyright will typically pass from the author (i.e. the developer) to the employer pursuant to law and/or the employment contract. In general, the copyright holder has an exclusive right to prevent others from making copies of the work (source code or documentation) and to make it available to the public. Reversely, this means that the source code or documentation may only be copied and distributed to others with the permission of the copyright holder. Such permission is generally referred to as a license. Before making a contribution of copyright-protected material, consider the following: @@ -45,7 +47,9 @@ Before making a contribution of copyright-protected material, consider the follo * 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[^ai-copyright]. + +[^ai-copyright]: [Computer Love: Beijing Court Finds AI-Generated Image is Copyrightable in Split with United States](https://www.natlawreview.com/article/computer-love-beijing-court-finds-ai-generated-image-copyrightable-split-united){:target="_blank"}, The National Law Review Apart from copyright, a contribution may also be subject to other third party rights. For instance: @@ -61,15 +65,21 @@ From the legal perspective, the company will normally not assign or transfer its 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[^asl2.0]. + +[^asl2.0]: [Apache License 2.0](https://www.apache.org/licenses/LICENSE-2.0){:target="_blank"} * 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. -* 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)[^dco]. 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. + +[^dco]: [Developer Certificate of Origin](https://developercertificate.org/){:target="_blank"} -* 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[^ccla]. 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. + +[^ccla]: [Corporate Contributor License Agreement](https://www.apache.org/licenses/cla-corporate.pdf){:target="_blank"} * 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. @@ -93,6 +103,12 @@ Apart from what is stated above, participation in an open source software projec * 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. +* Larger open source software projects and/or Open Source Foundations may have their own antitrust guidelines[^lf-antitrust]. 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. + +[^lf-antitrust]: [Anti Trust Policy](https://www.linuxfoundation.org/legal/antitrust-policy){:target="_blank"}, Linux Foundation + +* 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[^lf-export-controls]. Certain technology fields may also in various jurisdictions be subject to special regulation[^eu-ai-act]. + +[^lf-export-controls]: [Understanding US export controls with open source projects](https://www.linuxfoundation.org/resources/publications/understanding-us-export-controls-with-open-source-projects){:target="_blank"} -* 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. +[^eu-ai-act]: Such as the planned EU AI Act, which is expected to exclude regulation of open source software for the most part but apply to open source software for the prohibited types of AI, and the planned Cyber Resilience Act, which may come to include requirements on upstream company contributors in terms of cybersecurity considerations. diff --git a/Contributions-3-3-Ind.md b/Contributions-3-3-Ind.md index e190100..62423e3 100644 --- a/Contributions-3-3-Ind.md +++ b/Contributions-3-3-Ind.md @@ -18,7 +18,9 @@ Deciding to create a new open source software project shares many of the same co * 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. +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[^todo-starting-a-oproject]. Further, the success of the project will depend on successful external community building. + +[^todo-starting-a-project]: [Starting Open Source Projects](https://todogroup.org/resources/guides/a-guide-to-outbound-open-source-software/#starting-open-source-projects){:target="_blank"} ### Defining the purpose of the open source software project @@ -26,7 +28,9 @@ Similar to what is described in module 3 for contributions to existing open sour 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. +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[^gpl3] – 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. + +[^gpl3]: [General Public License](https://www.gnu.org/licenses/gpl-3.0.html){:target="_blank"} 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.