Consolidate Emily Omier's content into existing guide structure#779
Consolidate Emily Omier's content into existing guide structure#779
Conversation
This PRs consolidates content from PRs #741, #742, and #744 into the correct directory structure: `whitepapers/business-value/content/en/` All content has been originally contributed by Emily Omier and she is the committer / author of these additions Signed-off-by: Ana Jimenez Santamaria <asantamaria@linuxfoundation.org>
✅ Deploy Preview for ospobook ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for ospomindmap canceled.
|
Signed-off-by: Ana Jimenez Santamaria <asantamaria@linuxfoundation.org>
Signed-off-by: Ana Jimenez Santamaria <asantamaria@linuxfoundation.org>
Signed-off-by: Ana Jimenez Santamaria <asantamaria@linuxfoundation.org>
Signed-off-by: Ana Jimenez Santamaria <asantamaria@linuxfoundation.org>
PR #741 (Add introduction)💬 GENERAL COMMENTS: • @eriksven: "Overall, I think it is a very good start. Most comments are small modifications or thoughts I had while reading." • @eriksven: "Is this PR outdated in favour of #744? It seems like #744 is an extension. If so, we could close this PR." • @anajsana: "These additions are great, but they don't follow the original structure. Would it be okay if I open a new PR to place these in the appropriate sections?" • @Delta456: "We don't need what_is_open_source.md because Introduction.md has the same content with more details." 📌 INLINE REVIEWS from @eriksven on Introduction.md:
|
PR #741more @eriksven inline reviews:
|
PR #742 (Expand glossary)📌 INLINE REVIEWS • @EmilyOmier responds: "I'm not sure it's worth referencing the OSPO glossary; it's not extensive enough and this glossary should include basic OS terms. It's important for it to be self-contained." |
PR #744 (Background, business benefits)📌 INLINE REVIEWS from @eriksven on EmilysTOC:
|
SUMMARY
|
anajsana
changed the title
|
@EmilyOmier is it possible to take a look at @eriksven's comments and make the necessary updates to the content? Let us know if you need help making changes to this PR. My suggestion is to go via review mode and make suggestions inline, so I can later commit those changes in the PR |
|
@anajsana I will have a look on Monday! |
|
@anajsana I'm not sure all the content is there; it seems like there introduction document is cut off. It's a bit confusing to look at the comments without seeing them in-line, but I can try. |
cornelius
left a comment
cornelius
left a comment
There was a problem hiding this comment.
I have now read all the sections. Thanks for putting all this together. I added a couple of inline comments and questions.
One structural question came to me, if we need another chapter at the end about strategy. So after we have explained and covered the different aspects of how to look at open source from a business point view, then turn this into some concrete advice how to use it strategically to reach business goals.
|
|
||
| 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. |
There was a problem hiding this comment.
Maybe mention the studies, e.g. the Synopsys study, which shows that for all projects the largest part of the supply chain is open source.
Also instead (or in addition to) the programming languages maybe mention the areas where open source dominates, which are also tangible for people looking at it from a less technical point of view. Web applications are almost always based on open source, mobile application as well, Android is open source. The cloud is only possible because it is built on a complete stack of open source software which (hyper-)scales, Linux, Kubernetes, etc.
|
|
||
| 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. |
There was a problem hiding this comment.
I would avoid the term "contributing back". This has a connotation that it's a charitable act. But from a business point of view, there is (and should be) a very selfish motivations to do so. It makes economic sense.
|
|
||
| ## 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. |
There was a problem hiding this comment.
Do we have numbers to quote for the percentage of companies with a formal open source strategy?
I'm not sure I follow the argument here. If businesses see the impact, shouldn't more have a strategy?
| ## Engagement levels 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. | ||
|
|
There was a problem hiding this comment.
We should add the diagram about the stages of adoption here: Deny, Use, Participate, Contribute, Lead.
|
|
||
| ### Using open source software | ||
|
|
||
| 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. |
There was a problem hiding this comment.
Is this really focused on the engineering department? I would say that open source has an effect across all parts of a company which use software, because it provides software without license costs, not only for engineering, but for all kind of other areas as well. In fact some of the most dominant software domains are mostly free because of open source, e.g. web browsers.
| - **Free software:** Free software is, generally speaking, software that is even more free than open source software. Users should have absolute freedom to do whatever they want with the software. Free software is considered the philosophy behind open source, whereas open source is an attempt to operationalize the ideas behind free software. | ||
| - **Copyleft license:** A type of open source license that gives users somewhat fewer rights. The most notable difference between a permissive and a copyleft license is that under copyleft licenses, users have to distribute any derivative works under the same license, and can't develop paid products from the source code. When the company behind an open source project is trying to monetize their project, this can protect them from competitors taking their source code and creating a directly competing product. However, it can also create problems for enterprises that need to incorporate open source code into their own software products. | ||
| - **Permissive license:** A type of open source license that gives users broad rights to use, change, distribute and even create competing software products with the code. The most common permissive open source licenses are MIT and BSD licenses. | ||
| - **Contributor agreement:** A legal agreement that contributors, particularly code contributors, sign before their contributions are accepted. Contributor agreements often cover things like copyright assignment and licensing; they can become extremely important if the project's license is ever changed. Contributor agreements are also critical if there is a plan for monetizing the project. It's a good practice to put in place a contributor agreement before accepting contributions from anyone. |
There was a problem hiding this comment.
I would disagree with this. Contributor agreements are a bad practice, because they erect barriers for contributions. In an asymmetric project, where the owner of the project retains more rights than its contributors, e.g. for releasing a proprietary version, they are necessary, but that is a fine balance to strike and leads to discussions such as open core and other models.
I would suggest to keep the definition in the glossary neutral and discuss the implications of contributor agreements in a dedicated section in one of the chapters. They do have influence on the business model, but not necessarily in favor of the users or contributors.
| - **License:** The legal conditions under which a software product can be used. There are many types of software licenses. They stipulate how, and by whom, the software can be used. An open source license doesn't mean complete freedom to do whatever you want with the code, there are still certain conditions that have to be met in order to be in compliance with the license. | ||
| - **Steering committee:** *(To be completed)* | ||
| - **Working group:** *(To be completed)* | ||
| - **Free software:** Free software is, generally speaking, software that is even more free than open source software. Users should have absolute freedom to do whatever they want with the software. Free software is considered the philosophy behind open source, whereas open source is an attempt to operationalize the ideas behind free software. |
There was a problem hiding this comment.
I wouldn't say that free software is more free than open source software. In terms of licensing they are more or less equivalent. It's more a cultural difference, but depending on where you are the terms are more or less interchangable.
|
|
||
| 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. |
There was a problem hiding this comment.
I would add here that it's about talking to people whose work is driven more from the business side and not the technical side. So it's about other factors, motivations and incentives which guide decisions. Not being familiar with open source or having misconceptions is a secondary part, from my point of view.
|
|
||
| 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 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. |
There was a problem hiding this comment.
I think this is an important aspect to cover, but is the introduction the right place? I would rather put it in a section where we talk about collaboration models.
|
|
||
| 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. |
There was a problem hiding this comment.
I think we should not only focus on contributions, but also on "active" use of open source software. For a business it can make a huge difference, if it's actively looking for open source alternatives to proprietary software, even without considering contributions. So I would not separate between use and contribute but between treating open source consciously and purposefully vs. letting it passively happen. That's what makes the difference to the business.
3 participants
This PRs consolidates content from PRs #741, #742, and #744 into the correct directory structure:
whitepapers/business-value/content/en/All content has been originally contributed by @EmilyOmier and she is the committer / author of these additions