Background, business benefits

whitepapers/business-value/EmilysTOC

@@ -0,0 +1,67 @@
+---
+title: Table of Contents
+weight: 5
+---
+
+## Definition of Open Source 
+
+- The legal definition, plus background on the open source movement
+        - Permissive licenses and copyleft licenses 
+- The difference between 'legally' open source and the open source philosophy
+- Desciption of common practices in open source development
+- Misconceptions about open source 
+
+## Open source glossary
+
+- Glossary of terms 
+
+## [Background - Existing frameworks and models]({{< relref "glossary" >}})
+
+- Guide's purpose and audience
+- Open source in modern software engineering
+- Open source in modern businesses 
+- Engagement levels in open source 
+    - Using open source software
+    - Contributing to open source software
+    - Publishing and maintaining open source software
+- Carl-Eric Mols' "Principles for Industrial Open Source"
+- Magnus presentation at FOSSNorth
+- Mozilla archetypes and Heather Meeker's frameworks
+
+## Business benefits of open source software
+- Engineering benefits
+- Marketing + sales benefits
+- Other business benefits (recruiting, retention, reputation) 
+- Difference in business benefits depending on the engagement level (user, contributor, editor) 
+- Strategies for maximizing the business benefits of open source
+
+## [Open source has downsides, too]({{< relref "misconceptions_challenges" >}})
+
+- Risks and challenges from using open source software
+- Risks and challenges from contributing to open source software
+- Risks and challenges from publishing and maintaining open source software
+    - Cyber Resilience Act (CRA) when publishing software
+- Legislative risks related to open source software
+- How to properly budget or allocate resources for OSPOs?
+- Strategies for minimizing the risks and downsides from open source
+
+## [Communicating open source's value with business stakeholders]({{< relref "communication_of_benefits_to_business_value" >}})
+
+- Adjusting your message according to your audience - not all business stakeholders are the same 
+- Focus on the 2 or 3 primary benefits you think this particular project will have; all projects are different 
+- Don't hide the drawbacks of open source; be frank about the potential risks and downsides
+
+## [Case Studies and Success Stories]({{< relref "case_studies_and_stories" >}})
+
+- Neutral collaboration: Stories from organizations like LF Energy's OpenSTEF or from Open Telemetry
+- Case study from open source 'user' organizations
+- Case study from organizations who are engaged contributors 
+- Case study from publishers of open source software 
+
+## Should I open source this software?  
+- Framework for deciding whether your organization should release an internal project as an open source project
+
+## [Future work and conclusion]({{< relref "living_guide_for_business" >}})
+
+- Creating a living document that evolves with community input
+- Recap of the guide's key points  

whitepapers/business-value/Introduction.md

@@ -0,0 +1,119 @@
+# What is open source? 
+
+When it comes to open source, there are a lot of misconceptions – even among software engineers. So what exactly is open source? 
+
+Open source software has its roots in the free software movement, which started in the 1970s. Software was the first ‘digital product.’ Long before there were digital music or digital books, you could create a copy of a software program for free, without any impact on the original program. This gave rise to a political philosophy that holds that programmers shouldn’t charge for software, and that software should be a source of empowerment for users. The ‘free’ in the free software movement is a reference to freedom, not to something that costs $0. There are four basic freedoms of the free software movement: 
+
+- Freedom to run the program as you wish, for any purpose
+- The freedom to study how the program works, and change it to make it do what you wish
+- The freedom to redistribute copies so you can help others
+- The freedom to distribute copies of your modified versions to others
+
+The open source software movement takes the philosophy of the free software movement and codifies it, creating a legal framework around free software to make it more palatable to businesses – particularly their legal departments. 
+
+The organization in charge of translating the philosophy of open source software into concrete legal terms is the [Open Source Initiative](https://opensource.org), also known as OSI. All software is released under a software license, and the OSI determines which licenses are open source licenses. You can see the list of OSI-approved licences [here](https://opensource.org/licenses). 
+
+Open source software is simply software that is released under an OSI-approved license. 
+
+It can be published anywhere, it can be created and maintained by volunteers or employees at AWS, it can be used for good and it can be used for evil. It can be produced by a single individual or a group, it can be a product of collaboration between multiple companies or it can be created entirely by a single company. Open source software is not fundamentally ethically or morally superior to proprietary software; it is a development model that can have both advantages and disadvantages. 
+
+If the software is published under an OSI-approved license, it is open source software. Conversely, software that is not published under an OSI-approved license is not open source. 
+
+The above point is important, because there are actors in the ecosystem that have tried to muddy the definition of open source, or have tried to position open source as a spectrum. Open source is not a spectrum; either a piece of software has an OSI-approved license or it does not. 
+
+You can see the full description of the [criteria OSI uses](https://opensource.org/osd) to determine whether or not a particular license meets their criteria here; in a nutshell, a license must meet the following criteria: 
+
+
+1. Free redistribution. 
+2. Availability of source code.
+3. Freedom to create derivative works 
+4. No discrimination against people or groups 
+5. No discrimination against use cases 
+
+
+Some of these clauses seem straightforward at first glance but in fact are not. For example, open source software can’t be restricted to use cases that the program author considers ‘good.’ An open source software can be used as part of a spyware or cyberwarfare stack for an enemy state; it can be used in weapons technology. Open source software can be used by the software author’s commercial competitors. It’s possible to limit who contributes to the software because contributions require approval from a maintainer, but it is not possible to limit who uses and benefits from the software. 
+
+
+
+## Legally open source versus culturally open source 
+
+Much of the confusion around what is and is not open source comes down to the fact that while open source has a legal definition, there is a larger philosophy and culture around open source. There are also a set of common practices related to open source software that are described below. It’s important to note that while these practices are strongly associated with open source, they do not define a piece of software as open source. For example, just because code is available publicly on GitHub does not mean that it is open source code; there are many non-open-source licenses in which the code is public but published under a license that does not meet the OSI’s criteria for an open source licence. Conversely, not all open source software is available on GitHub. It could be available on GitLab, but also for download directly from a website or, if you want to travel back in time, on a floppy disk. 
+
+### Collaboration
+
+In most cases, open source software is published in a public repository on GitHub or on GitLab. This is a way to both make the code publicly available, and to facilitate collaboration. 
+
+Not all software published on GitHub is published under an open source license; conversely, a software that is, for example, available for download directly from the creators’ website but available with an open source license is open source. That is true even if there is no easy way to collaborate on the software. 
+Collaboration
+
+The reason that open source software is so closely associated with GitHub and GitLab is because collaboration is a core part of open source culture. 
+
+Open source software is used all over the world, and it’s free. While it is certainly not the case in all open source projects, many open source projects really are a collaborative effort. The people who work on the project can be a mixture of volunteers and people who are paid for their work on open source; they can be employees at companies that compete with each other. They can live all over the world, have different skill sets and vastly different economic realities. There can be one maintainer or several maintainers; the level of engagement with the project can vary drastically while still remaining a communal effort. 
+
+When software developers think about open source software, they often think about projects like Linux – projects that are created exactly as described above, with a huge network of people who find a way to work together in spite of vastly different realities. 
+
+Collaboration can be both a strength and a weakness of open source. When it works well, you get input from people with a wide variety of use cases for the software, with each person contributing according to his or her strengths. This makes it possible for the software to be developed much more quickly; it also means that bugs are caught and fixed quicker. 
+
+On the other hand, collaboration is not always easy and there are downsides. Open source projects can suffer from being pulled in a million different directions; they can also get bogged down with poor-quality code submissions, comments or issues that are opened that don’t make sense or are redundant and waste time, and differing opinions about how to solve the same problem. 
+
+Collaboration is considered part of the ‘spirit’ of open source. But the idea that all open source projects are the product of collaboration among otherwise unconnected developers is largely a myth. There are many open source projects that are created, developed and maintained by a single individual; there are many open source projects that are created and maintained by multiple people who work at the same organization, so that the effect is no more ‘collaborative’ than any other piece of software that is developed internally. 
+
+### Transparency 
+
+A second pillar of open source culture is transparency. In an ‘ideal’ open source world, this means that everything about the project is done in the open: Issues are raised publicly, there is public discussion about the roadmap, and the code is developed incrementally, in the open. Technical decisions can and should be made transparently. 
+
+Clearly at least a minimal amount of transparency is necessary for open source software to be open source, given that the code must be publicly available. However, it’s entirely possible to publish an open source project under an OSI-approved license without being transparent about the process. In the open source world this is called a code dump; when the code is written entirely internally and then the finished product is published under an open source license. A code dump is a pejorative term; it is considered not at all in the spirit of open source. 
+
+Transparency can be uncomfortable, particularly for companies. Many companies hesitate to publish open source software precisely because they are worried about airing their dirty laundry, or about the world seeing their less-than-perfect engineering practices. True transparency also goes along with collaboration – if you are transparent about how decisions are being made, you are also opening yourself up to input from users. 
+
+### Community
+
+The expectation in open source projects is not just that individuals are going to collaborate, it is that they are also going to bond with each other and become a community. 
+
+In conversations around open source, there will invariably be talk of community. So what exactly does this mean? 
+
+Just as collaboration is one of the core values in open source philosophy, so is community. For an open source idealist, the goal isn’t just to build great software that solves a real problem; it is also to bring together like-minded people to work together and interact with each other. At its best, open source is not just about software, it is about the humans who make software. 
+
+Community can take many different forms. The most basic form in an open source project is on GitHub, in the form of both discussions and issues. These are ways for developers to talk about bugs they find in the software, to discuss additional functionality that should be added to the project and to consider different ways to solve technical problems. 
+
+In many open source projects, there’s also a Slack or Discord group for project users to connect with each other, ask questions, and support each other. Sometimes this is referred to as “the community.”
+
+The most successful examples of community building in open source projects happen when the project maintainers are able to bring people together in real life to collaborate and learn from each other. Sometimes these are small local meetups, sometimes these are large conferences (like KubeCon). 
+Just like with collaboration and community, however, you do not need to build a community in order to publish an open source software. And communities do not happen by magic; if you do not make a concerted effort to build the community, it’s not likely (although not impossible) that one will coalesce around the project you create. 
+
+In fact, communities do not make sense for all projects. So while community building is a core value in open source, not all open source projects will have a community and not all open source projects would even benefit from a community. 
+
+## Pull box: Different levels of engagement inside a community
+
+
+In an open source project, there are a variety of levels of engagement in the community (as with in any community).
+
+### Users
+
+In any open source community, the vast majority of people are simply anonymous users. One of the challenges for the maintainers of open source projects is that there is so little information about these people – other than statistics about downloads, it’s often hard to know what’s going on. 
+
+It’s also hard to know if people who download the project even use it. This lack of information about 95% of the users of the open source project is a source of frustration for creators and maintainers; and while it’s possible to get some metrics, for the most part you have to accept that you won’t have much visibility into this part of the community. 
+
+### People who ask questions and report bugs
+
+It’s generally less than 5% of the anonymous users who end up interacting with the community in any way. But someone who logs in to the Slack or Discord group just to ask questions is participating in the community; he or she is giving clues to potential problems with the user experience or the documentation as well as identifying themselves and giving you information about how they use the software. 
+
+These active community members are often overlooked when talking about open source communities, because there is so much focus on contributors, especially code contributors. It’s also why there is no shorthand term for project users who are active in the community but not contributors. 
+
+### People who answer questions
+
+In healthy open source communities, there is a type of community member who is incredibly valuable but often overlooked: people who are out there giving free support to others. In other words, those who are active in discussions and who answer others’ questions. 
+
+These people may or may not contribute to the project in the sense of contributing code or documentation, but they are providing an incredible service to the project and the community. There’s no short-hand term for these people, but these are the people who build a community around a project – even more so than those who are contributing code or documentation. 
+
+### Contributors 
+
+Contributors are people who contribute concretely to the project’s development. In the open source ecosystem, people tend to talk primarily about code contributors, but there are many ways that individuals can contribute to an open source project. It can be by writing documentation, by translating documentation (or translating the UX), writing website copy, by doing a conference talk about the project… or many other things. 
+
+### Maintainers
+
+Maintainers are the individuals who hold the keys to the project. They are the ones who decide what direction to take the project in, what contributions to accept and which ones to reject, which features to prioritize. 
+
+At first, the maintainers are the project creator(s), but in order to ensure project continuity it’s important to recruit additional maintainers. Large projects have multiple maintainers, and having more than one maintainer is an important sign of project health. 
+
+End pull box