diff --git a/whitepapers/business-value/EmilysTOC b/whitepapers/business-value/EmilysTOC new file mode 100644 index 00000000..ad218b3e --- /dev/null +++ b/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   diff --git a/whitepapers/business-value/Introduction.md b/whitepapers/business-value/Introduction.md new file mode 100644 index 00000000..6d76868c --- /dev/null +++ b/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 diff --git a/whitepapers/business-value/background.md b/whitepapers/business-value/background.md new file mode 100644 index 00000000..5d3b422f --- /dev/null +++ b/whitepapers/business-value/background.md @@ -0,0 +1,74 @@ +# Background + +## Purpose of this guide + +For the people who work in open source program offices and/or are involved in open source, the inability to convince their business counterparts to become more involved is a source of frustration. Open source champions know that their companies are missing out on opportunities to build value for the business, but they don’t have the right arguments to get the rest of the company on board. This is reflected in the fact that only 36% of organizations have a formal open source strategy, according to research done by the [Linux Foundation](https://www.linuxfoundation.org/hubfs/Research%20Reports/2025GlobalSpotlight_Oct-27-2025%20V4.pdf?hsLang=en). + +The goal of this guide is to give open source champions the arguments they need to have more productive conversations with those in the business who aren’t familiar with open source – or those who have misconceptions about what open source is and how businesses can get value from it. + +This guide is primarily focused on the benefits from not just passively using open source software, but also becoming active members of open source communities and/or publishing internal software projects as open source projects. In most organizations, using open source anonymously is uncontroversial – at any rate, everyone does it, whether or not the business stakeholders are aware that it is happening. The fact that open source is used ubiquitously throughout the business world is something that business leaders should be aware of and accept; if nothing else, it’s important to be aware of the organization’s open source usage because there are risks associated with using open source – it’s important to have the software bill of materials (SBOM) and to be aware of legal risks from the licenses. + +However, the potential for a true strategic relationship with the open source ecosystem opens up when organizations become active participants in the open source ecosystem, both by becoming active members of open source communities and by creating and maintaining their own projects and communities. + +One thing to note before going further, however, is to note that in open source maintainers, users and contributors are individuals. While organizations can own repositories and they can own trademarks and copyrights, contributions to open source projects have to come from individuals. It’s individuals who write and commit code, individuals who submit issues, individuals who submit pull requests and individuals who approve them. When you hire someone who’s been involved in open source, as an organization you benefit from the reputation they’ve built over the years in the open source community. Conversely, when an employee who has been involved in a project leaves your organization, they take with them the reputation they’ve built – and they can also take with them commit rights and maintainership of projects. When you’re just downloading and using open source projects this doesn’t matter much, but when the organization begins to have an open source strategy, it can become critical to be aware of and manage. + +## Open source in modern software engineering + +Nearly all software engineers use open source software, and most use open source software on a daily basis. + +Research from [Harvard Business School](https://www.hbs.edu/faculty/Pages/item.aspx?num=65230) shows that the value of open source software in the global market is around $8.8 trillion – that is, businesses would have to spend nearly $9 trillion to create and maintain software internally if open source software did not exist. Businesses would have to spend 3.5 times more on engineering if it were not for open source software. + +Open source software is ubiquitous in modern software engineering. Most programming languages are open source, and there are certain parts of the technical stack – libraries, for example – that are nearly always open source. If you think your organization doesn’t use open source, you’re almost certainly wrong. If you use Docker containers, you’re using open source; if you use Go or Java or Python, you use open source. + +The fact that using open source software makes engineering teams more productive is not controversial – it amounts to downloading software components and using them for free. But engineering departments can also become more involved in open source communities by contributing back to projects they use regularly and/or publishing their own open source projects. In most engineering departments, using open source software is simply the water that everyone is swimming in. Engineers don’t think much about downloading and using open source software because it is so integrated into their workflow. + +While the productivity gains from using open source software are obvious, there are risks to open source software, particularly to an approach to using open source by the rest of the business that either doesn’t acknowledge that open source is used or treats it as purely an engineering issue. Without external guidance, many engineers don’t know or don’t think to verify the software bill of materials (SBOM) for open source components they use. Engineers are not lawyers, and not all open source licenses are identical. Absent a clearly defined open source policy, companies can find themselves in violation of open source licences simply because their engineers don’t know which licenses are acceptable. + +As individual engineers and engineering departments in general become more involved in open source, however, there can be additional questions that arise. An engineer who fixes a bug or writes a custom extension for a project he or she uses, for example, has to decide whether or not to contribute that work back to the project. There are obvious reasons for contributing that work back to the project; among other things is that doing so means that others can use the bug fix / custom extension or other functionality themselves, and then use the additional time they save to develop some other extension or fix some other bug. In other words, the entire ecosystem benefits. + +However, not all organizations allow engineers to contribute their bug fixes or other work back to open source projects. In fact, in most cases it isn’t clear to engineers whether or not they are allowed, which in some ways is even worse. The lack of a clear policy as to when an engineer can and can not contribute their work back to the community can have a chilling effect on the organization’s ability to interact with the open source ecosystem. + +## Open source in modern businesses + +The relatively low percentage of companies that have a formal open source strategy shows that the majority of businesses, particularly those who are outside of the software industry, see how open source impacts not just the engineering department, but the rest of the business as well. + +The engineering productivity benefits that come from using open source software benefit the entire business, of course. They mean that software projects are finished faster, with a lower headcount, than would otherwise be possible. For any company that creates software of any kind internally, this has obvious benefits. + +Whether or not open source plays an active role in the larger business, outside of simple productivity gains in the engineering department, depends on whether or not the company has an open source strategy. If they do not, and the company’s engineers are primarily users, rather than contributors and/or publishers, in the open source community, they’re not likely to get much else. However, open source can become a competitive advantage for companies, including those who are not strictly ‘software’ companies, if they know how to engage with open source communities and exploit the potential benefits from open source. + +## Types of engagement in open source + +There are multiple ways that companies can engage with open source. The most basic way is by using open source; nearly all companies that develop software are users of open source software. In some categories, like software libraries and even programming languages, it’s nearly impossible to avoid open source. But a company can also become actively involved in open source projects, and can also publish and maintain projects as well. The business benefits from each type of engagement are different, as are the roles that open source will end up playing in the business. + + +### Using open source + +Open source is everywhere in software engineering, and your engineers are using open source software whether you like it or not. As a user of open source software, the main business benefit you’ll accrue are from increasing the productivity of your engineering department. For a business audience, the most important takeaway is that using open source is not really optional; completely avoiding open source would put a company at a massive disadvantage compared to their peers. + +### Contributing to open source + +While most people think primarily about code contributions when they think about contributing to open source software, for the purpose of this guide the definition is broader: If you’re more than an anonymous user – you ask questions, you answer questions, you participate in activities around the project – you’re a contributor. + +Given the thousands of open source projects an organization is likely to integrate into their stack, not to mention open source applications they might use, even outside of the engineering department, it’s impossible to get involved in all of them. For the majority of the open source projects you use, you will be an anonymous user. That is how the open source ecosystem is supposed to work. + +But some projects are going to be more important for your company’s success than others. In these situations, it can make sense, from an engineering and business perspective, to get involved in the project. The reason you do this isn’t to “give back,” it’s because it is in your company’s best interest. When a project is important for the company, getting involved in the project both creates business value and also mitigates risk. + +There are many ways to become involved in an open source project. Simply asking questions in the community has value; it tells the rest of the community and the maintainers where people are having trouble and points to potential improvements in both user experience and documentation. Answering questions, helping with design, writing website copy, writing blog posts about the project on your own company website, contributing code, sponsoring foundations, sponsoring conferences, organizing meetups – these are all ways that you can contribute as an organization to a project’s success. + +While there are advantages to each type of contribution, the core value proposition is the same: you are helping ensure that the project continues to exist, and you are building a relationship with the community. Building the relationship with the community means that if you need something in the future – a bug fixed quickly, a new feature added – your voice is more likely to be listened to. Multiplied throughout the ecosystem, it means that others in the community are able to work together and your force is multiplied. + +Becoming involved with open source projects can also increase the visibility of your company – in other words, it can be a marketing play. Every time an engineer from your company interacts with the open source communities they are a part of, it increases the visibility of the company a little. In a pure engineering context, this can ultimately help with recruitment, particularly for engineers. But depending on the industry you work in, the marketing and visibility the company can get by having individuals involved in open source projects is powerful. + +Another concrete benefit organizations can get from increasing their involvement with open source communities is increasing the skills of their engineering team. Having their work public pushes engineers to improve the quality of their code and to follow best practices; organizations that contribute to open source projects report that it increases the quality of their codebase and the overall skill level of their engineering team. + +### Publishing and maintaining open source projects + +What about taking software that you’ve developed internally, and publishing that software under an open source license? What about investing in continual maintenance of that open source software that can now be used by your competitors? + +This is the type of relationship with the open source community that most business leaders find hard to understand. Instead of taking something for free, your company is spending money in the form of engineering resources and then providing the result to others for free. Even your competitors can use the end result! Why would anyone do this? + +Not all software you develop internally is a good fit for being published as an open source project, but some of it is. If a project doesn’t directly give your company a competitive advantage, it might be a good fit for publishing as an open source project. + +### Carl-Eric Mols' "Principles for Industrial Open Source" +### Magnus presentation at FOSSNorth +### Mozilla archetypes and Heather Meeker's frameworks diff --git a/whitepapers/business-value/business-benefits.md b/whitepapers/business-value/business-benefits.md new file mode 100644 index 00000000..cb0b7511 --- /dev/null +++ b/whitepapers/business-value/business-benefits.md @@ -0,0 +1,152 @@ +# Business Benefits + +### Innovation + +Even by just using open source projects, you’re able to take advantage of the experiences of a wide range of use cases, individuals and industries. When you become involved in open source projects and even publish your own, you’re able to more quickly see how a piece of software can be used in a variety of novel situations, and to get feedback on use cases and edge cases quickly. + +Open source projects have a much shorter feedback loop than closed-source projects. If you develop a piece of software primarily for internal use (ie, you are not a software vendor), the only feedback you’ll get is from users inside the company. As a result, you’ll likely miss a number of potential ways the software could be used, and you won’t see the situations where it could be used in different industries. + +### Improved engineering quality + +One of the frequently cited advantages to becoming involved in open source is upskilling; in open source communities people mention the advantage of having many eyes examining the code for potential bugs, security or otherwise. Regardless, there is a psychological effect to knowing that your work will be visible to the entire world that tends to push engineers to write cleaner code. Multiplied over years of practice and over the entirety of your engineering team, this can amount to a significant improvement in engineering quality without any specific training. + +However, improvements to the engineering quality come from more than just the bright light shone on the codebase. Engaging with open source communities also gives engineers exposure to a wider range of experiences and a wider range of mentors. The number of people they will get feedback from is expanded, and as a result their skill level will improve. + +### Improved engineering velocity + +There is no doubt that open source in general increases engineering velocity, even for those who are simply users of open source software without any additional involvement in the community. + +For engineering teams that become contributors or who publish and maintain their own projects, the velocity advantages can be significant as well, although it’s not always obvious organizations get additional velocity benefits from deepening their involvement in open source. + +Let’s start with the advantages of contributing back bug fixes and new features for projects that your organization uses on a regular basis. First of all, the fact that your organization contributes back to your bug fixes means that others in the community will be able to work on other issues, whether it is fixing other bugs or working on new development. If it’s a project that you use, the act of contributing the work you would need to do anyway back to the community pushes the project forward that much faster; multiplied by all the organizations who rely on the project it means that the project will move forward substantially faster. + +In addition, the act of contributing to the project deepens the team’s understanding of how the project works. GitLab has a program in place to encourage paying customers to contribute code to the open source project; they find that when customers do so, they end up taking advantage of GitLab more than they would otherwise. Becoming involved in the project and contributing back bug fixes has a similar effect with other projects. + +But there’s also the case of publishing internal software projects as open source projects. In some cases, this doesn’t accomplish much, because the project just sits on GitHub without attracting much attention from anyone. However, if you are able to build a community around an internal software project that’s published as open source, you’ll often be able to recruit others to help with the development – or to find projects that already exist and provide the same outcome, and join forces with those maintainers. + + + +### Relationships with others + +One of the many things that make open source different from closed source software is that open source is fundamentally not just about building a software product, it is about building relationships between individuals and between organizations. + +The advantage for individuals is relatively obvious: The relationships they build while contributing to and/or publishing and maintaining an open source project as part of their day job can help them improve their own skills, build their network and lead to additional professional opportunities in the future. For the organizations they work for, collaborating with others, both those who work in similar fields and those who work in completely different fields, can provide benefits both related to the software project they are working on, and beyond as well. + +For organizations that aren’t competitors but who work in related industries, the relationships that are built through open source projects can lead to other opportunities for joint projects. This can turn into joint marketing efforts, products that are packaged together and other commercial opportunities that go far beyond the software project that originally brought the two companies together. + +These relationships also give your team members others to turn to when faced with a challenge they don’t know how to handle, whether it’s related directly to the open source project that brought them together or to some other challenge. + +Being involved in existing open source projects will certainly build peer-to-peer relationships between your team members and their counterparts at other companies; writing, publishing and maintaining your own open source projects gives your organization the opportunities to be the center of a community of interest that brings together a group of peers. It is also possible for two or more organizations to collaborate on writing, publishing and maintaining an open source project together. It’s more common for one organization to write the initial project and then recruit additional maintainers from other organizations, but both scenarios can create relationships between individuals and between organizations that lead to additional commercial and technical opportunities. + +### Recruitment + +Does your organization have trouble recruiting engineers? Is the process of onboarding new engineers long and burdensome for everyone? Because if so, becoming more involved in open source is one of the best ways to recruit engineers; it also helps evaluate the skill level of engineers much more accurately than any code test, and can speed up the onboarding process dramatically. + +Whether you get involved in open source projects by contributing to existing projects or by publishing your own internal software as open source projects, the team members who manage the relationship with open source are going to develop relationships with others in the community. That can lead to additional commercial opportunities as discussed above, but it also means that there’s a ready pool of people who are already known to your engineers. Assuming, of course, that your organisation is a respected member of the community you are in, your company will also be a more attractive workplace than others. According to the Linux Foundation’s State of Open Source in 2025, 74% of the professionals surveyed think that being involved with open source makes the company more attractive for talent. + +In addition, if you recruit an engineer who works on an open source project that your team is also involved in, you are able to evaluate his or her skill level much more accurately than in a coding test. You’ll see their pull requests and you’ll see the issues they report. Just as importantly, you’ll be able to see how they interact with others in the community and their ability to collaborate with others in a healthy way. In other words, you’re able to dramatically de-risk your hiring decisions. From the perspective of the potential recruit, the exact same thing is true: they have much more information about your organization and the way you work than would be possible in any other situation. In other words, they are also able to derisk the decision to take a job with you. + +When it comes to onboarding, someone you know through an open source project you are both already involved in comes with the huge advantage of already being completely up to speed about at least one project that the organization works on. They can continue contributing to the project on day one. Just as importantly, your team is likely to have a good idea of the new recruit’s strengths and weaknesses even before they start, and can adjust the onboarding process accordingly. + +### Retention + +Generally speaking, engineers want the ability to contribute to open source projects, and potentially create their own open source projects. If they are able to do so as part of their job, they are more likely to stay. In the Linux Foundation State of Global Open Source 2025 report, 78% of people surveyed said that being involved in open source makes the organization a better place to work. So while being involved in open source is likely to improve your team members overall skill level and will open up additional career opportunities for them, it will also increase their loyalty to the organization, because they know that not all organizations will allow them to continue their involvement in open source. + +Even if your internal software isn’t particularly cutting edge, or if your engineers aren’t particularly challenged by their day-to-day, your team can continue to develop their skills + +### Visibility + +Being involved in open source is an additional "marketing" channel that will increase your organization's visibility. When it comes to recruiting developers, this can be particularly important, as mentioned above. But recruiting is not the only reason your organization might want to increase its visibility; being involved in open source projects will help. + +The advantages of increased visibility are most obvious for companies that create and sell software. For this type of company, being involved in open source can directly lead to new customers, since their target customers are likely to be involved with open source projects and aware of which organization are involved as well. But even for non-software companies, for whom the software engineers are not necessarily the target market, a presence in open source will increase the organization's overall visibility. + +In addition, not all open source projects are primarily used by software engineers! Some open source projects are truly deep-tech, used only by programmers. But many others are industry-specific, with end users who are not technical. While getting involved with deep tech projects will increase an organization's visibility with programmers, getting invovled in industry-specific open source projects will increase the organization's profile in the specific industry they work in, among potential customers and potential partners. + +### Reputation + +Participating in open source communities, even if it's your engineering team who is participating, can build the organization's reputation and brand. An organization that contributes to and/or maintains open source projects is able to showcase the quality of the engineering, which can help both with recruitment but also, for companies that sell software of any kind, in building trust among customers. + +The reputation benefits of being involved in open source go beyond just showcasing your in-house engineering skills, particularly if the organization is involved not just at the level of contributing code, but also is part of a project's maintainer team and a visible project supporter. Imagine your organization supports a security-related project, both by employing engineers who work on the project and also by providing financing and/or other support for the project. The fact that you are involved in the project will improve your organization's repuation as a company that cares about security and has the internal expertise to ensure the security of their software. If your customers and collaborators care about security, this improved reputation can directly help your company land deals and seal partnerships. + +There is, of course, a reputational risk from open source: It is always better to not do something at all than to do it poorly, and that is especially true when it comes to something as public as an open source project. If your code is sloppy, or if your team members behave badly towards others in the open source communities you're involved in, your organization will take a reputational hit. That is one of the reasons it is a good idea to have organizational policies related to open source -- if your engineering team is treating open source communities like the wild west, it could hurt the organization's reputation. + +### Trust + +An element of your organization's reputation is trust. Contributing to open source projects, and creating and maintaining open source projects, will help your organization build trust throughout the ecosystem, with different types of stakeholders -- potential employees, current employees, investors, partners, customers. Assuming, of course, that you do it well. + +Being involved in open source builds trust in a couple different ways. First of all, there is transperancy. The more of your codebase that is available for partners, employees and customers to see for themselves, the more they can verify that your software does exactly what it says it does -- and nothing else. The fact that you are not asking people to trust you at all, but are giving them the possibility to check it out for themselves, builds trust over time as they see that you are not hiding anything. + +The second kind of trust you can build has to do with the way the company behaves in the open source ecosystems it is part of. Is it a productive member of the community? Does the company invest over the long term, or show up suddenly to make demands without investing in building a relationship with others in the project? Do people who work for your organization treat others in the open source ecosystem with respect? If your organization behaves well in open source communities, partners, employees and customers are more likely to trust that your organization will behave well in other situations as well. + +### New opportunities + +Being involved in open source communities, whether by creating and maintaining a project or by becoming active contributors and community members in an existing project, can create additional business opportunities and potentially new revenue streams. + +The best example of this dynamic is [Backstage](https://backstage.io), the project developed originally by Spotify and donated to the CNCF in 2020. Spotify's primary business has nothing to do with developer portals or developer tools at all, but since Backstage's success Spotify has explored monetizing the open source project they originally developed internally to fix the pain points related to a fast-growing engineering team. [Spotify now offers enterprise support, a Backstage portal and several paid Backstage plugins.](https://backstage.spotify.com/partners/spotify/bundle/spotify-plugins-bundle/) Not every open source project is going to end up as a revenue stream, but software projects that start as internal tools, are open sourced and then eventually spun off into new divisions or new companies are not that rare. + +But ultimately getting involved in open source can lead to additional business opportunties and additional revenue streams, whether it is directly monetizing an open source project or through the partnerships that open source collaboration encourages. + +## Strategies for maximizing the business benefits of open source + +While there are many potential benefits from getting involved in open source, they will not necessarily happen just because you've published a project on GitHub or because you've submitted a pull request to a project you depend on. An even more insidious problem is when an organization does in fact get benefits from its involvement in open source, but no one is really aware of what those benefits are or how much they are worth to the company. When that happens, it puts the organization's involvement in open source at risk, because business leaders are likely to cut it when budgets get tight. Then the business suffers, and no one really understands why. + +That's why it's important to be intentional about the organization's involvement in open source, and to communicate how the organization works with open source and what it expects to get out of that involvement. Organizations get the most out of open source when both engineering and business leaders understand why open source is important, and those strategic goals from open source are translated into concrete policies to guide individual employees' interactions with open source, from the policy on using open source anonymously to how and when to contribute to and/or publish and maintain your own open source project. + +### Audit your current open source involvement + +If your organization currently develops software, it almost certainly has some sort of involvement in open source already. So the first step to maximizing the business benefits you get from open source is figuring out what that involvement looks like. In surveys of open source usage, both business and engineering leaders dramatically underestimate open source usage in their organization, often because engineers consider open source so critical to their work that they take it for granted and don't discuss it with their leadership. + +Of course, there are other reasons to audit your involvement in open source! First of all, simply understanding which projects you use is important for security reasons; it's an important element of your software bill of materials (SBOM). But when it comes to open source projects, there's also the risk of a project being abandoned. When you audit your involvement in open source, you should try to evaluate the following: + +- Which projects do you have intregrated into your software stack? +- Which projects does your team use regularly? +- How critical is each project? If it were to go down, what would the impact on your organization be? How likely is it that you would be able to fix the problem internally? If the project goes down, would your customers be impacted at as well? +- Which projects are your employees involved in, above and beyond using the project anonymously, if any? +- If there are projects your employees are involved in, what does that involvement look like? What pushed them to get involved? +- Are there any projects that your company has published as open source projects? Who published them? Are they being maintained? Who owns the projects? + +In most organizations that have an established engineering department but little or no official open source governance, it's likely that even engineering leaders only see the tip of the iceberg when it comes to involvement in open source. So taking the time to fully evaluate what that involvement + +### Evaluate what you're getting out of open source right now + +For open source champions, one of the biggest sources of frustration when talking with their colleagues, particularly those outside the engineering department, is that they often have a hard time articulating exactly what the company gets out of open source. This happens because while there are typical ways that an organization can benefit from involvement in open source, each organization is unique. It's important for open source champions to be able to make a clear case to business stakeholders about what the organization gets out of open source right now before they can argue for deeper involvement in open source projects. + +The challenge is that benefits from open source are often -- but not always -- indirect. But the larger risk is that companies who don't recognize the benefits they are already getting from open source will cut back on their involvement in open source, thinking that there's no ROI, but then notice a decline in reputation, visibility or ability to recruit that they can't explain. + +Once you've done a complete audit of what the organization's current involvement in open source looks like, you can start evaluating what that involvement is doing for the organization. It might not be immediately clear what you're getting from open source! In that case, the best course of action is to establish hypothesis for how open source is benefiting the business, and test those hypothesis. + +### Establish a maximum of three strategic goals you want from open source + +As illustrated above, there are many different potential strategic reasons to get involved in open source. However, if you try to get everything from open source, you'll end up diluting your efforts and getting less out of your involvement with open source than otherwise. Instead, it's a good idea to choose a maximum of three strategic goals you have for your organization's involvement with open source, particularly in smaller organizations. + +In large organizations, there will likely be different strategic goals for different open source projects. In that case, it's a good practice to ensure that there are definied strategic goals each time a team either releases an internal software project as an open source project, or even starts to get involved as a serious contributor in an existing project. There shouldn't be more than 2 or 3 strategic goals from any specific project. + +Whether we're talking about the strategic goals from the company's overall involvement in open source or the strategic goals from involvement in a single project, the goals aren't set in stone. They can change, and in fact should be evaluated on a regular basis (quarterly or bi-annually) to ensure that the goals in mind are still in alignement with the company's overall priorities as well as to evaluate whether or not the involvement in open source is in fact meeting the goals you've set. + +### Create a written open source policy + +One of the common impediments to getting value out of involvement in open source is the lack of an organization-wide policy. + +### Measure your success (or lack thereof) + +### Get involved in the projects that are strategically important + +It's worth stating the obvious here: Your organization is not going to get involved with all the open source projects that it uses. You won't even get involved with all of the projects that are important to you; in most software stacks there is so much open source software that it's impossible to make even small meaningful contributions to all of them. However, you can identify open source projects that are particularly strategically important to your organization and become involved in them. There are many levels of involvedment in open source projects. If you fix a bug in a project, even if it's not particularly strategically important, there's no downside to your organization (or to the software engineer individually) to contributing the fix back to the project. Doing so allows others who use that project -- and the project maintainers -- to work on other things, which ultimately will benefit all project users, including you. If you have to write the fix anyway, contribute it back to the community. + +Aside from one-off bug fixes, the decision to get involved in a project should be made intentionally and strategically. In general, there are two categories of projects that organizations should prioritize for long-term involvement: Those that are particularly strategically important for the organization, and those that are important for the organization and are clearly underresourced / at risk of abandonment. + +**Strategically Important Projects** + +It takes time to become a trusted member of an open source community. If an individual or organization arrives in an open source community and immediately starts requesting new features or want to influence the roadmap, they will be at best ignored, at worst they'll find themselves blacklisted and have to dig themselves out of a reputational hole. + +If there's a project that's strategically important enough that your organization might need to influence the roadmap, or get a new feature integrated into the project -- even if you're organization is going to write the new feature itself -- it's a good idea to get involved in the community before you need something. + +The number of project you'll be able to get involved with at a strategic level depends on the size of your organization. But if you want to have the ability to influence the roadmap, or even just to get your PRs accepted in a timely manner, you should invest in becoming a member of the community before you need something urgently. + +**Neglected projects** + +Some projects are important, even critical, but don't necessarily have strategic importance for the organization. But when there's a project that's important to the organization and is at risk of abandonment, or simply isn't healthy, it can be a good idea for the organization to get involved. + + + +### Publish projects strategically diff --git a/whitepapers/business-value/what_is_open_source.md b/whitepapers/business-value/what_is_open_source.md new file mode 100644 index 00000000..945fe918 --- /dev/null +++ b/whitepapers/business-value/what_is_open_source.md @@ -0,0 +1,36 @@ +## 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 is software that can be freely used, shared and modified. The philosophy behind open source software has its roots in the free software movement and hacker culture of the 1970s; the free software movement believes that software should be freely available to users. The 'free' in free software refers to freedom, and the movement is based on the four freedoms of software. They are: + +0. Run the software whereever you want, for whatever purpose +1. The ability to study and modify the source code +2. The abilty to give away or sell the software +3. The ability to give away or sell modified version of the software + +Open source software has its roots in the free software movement, but it is a less extreme, less 'free' version. 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.  + +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.  + +The criteria that Open Source Initiative uses to determine whether or not a license will be approved are:  + + 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  + +You can see the full description of the criteria [OSI uses here](https://opensource.org/osd). + +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 cyber warfare stack for any 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.